Sure, it is quite easy to install python from source. Usually I am doing it because I need older version for work projects. Of course, the other thing that one needs in that kind of situations is virtual environments. This makes it also quite easy to ensure that you always run the correct python. Create a venv with a specific version of python and once you are in that venv, the 'python' command will automatically run that python version. That way it is easy to use an unlimited number of python version next to each other.
Absolutely. Both uv and pipenv tools are bad because they aren't necessary and they obscure how the programs that the programmer needs to use actually work. The fewer things the programmer uses to accomplish their goals, given they don't require (a lot of) extra effort, the better is the quality of the outcome.
To illustrate my point with an example: Python packaging has a lot of cargo cult because the overwhelming majority of Python programmers don't understand what needs to be done to accomplish the task of packaging their code and don't know how to verify that what they wanted to do was actually done.
One such ironically stupid and ubiquitous (but relatively harmless) detail is this: Python programmers are told to use pyproject.toml in order to, beside other things, configure the build of their distributable binary package (if the project intends to have one). It is very common to have [dev] and [test] sections in this sort of configuration, which Programmers might believe to describe their development or testing requirements... however, instead, they describe feature dependencies. Something completely different from what their authors intended.
The reason this happens is that it makes it easy to install development and/or testing dependencies by typing eg. "pip install -e '.[dev]'". And nobody looks into the resulting package metadata, where all these dependencies are listed in their respective feature sections...
This is not the only stupid thing that goes into the generated package metadata. There's the useless "Dynamic" metadata field declaration that serves absolutely no purpose, but is added by the build tools (and nobody ever examines the output). I've found that a lot of even very popular Python packages never look into the output of their builds and package a lot of useless garbage with whatever code they distribute (eg. for a long time NumPy were packaging their unit tests together with the rest of their code...). Tools like uv and pipenv certainly help with obfuscation and, subsequently, worsening the quality of the output.
If you use uv or pipenv, not only do you not prevent this problem, you actually make it a lot harder to get rid of it, because now you've added another tool to your toolchain that can't be used to do the right thing and pushes you even harder in the direction of doing the wrong thing.
Just sharing this, I was doing my routine this morning with a couple new VMs and was thinking how much I like building my Python environments from source.
Just wanted to share for anyone and show that it has certainly gotten easier over the years (though this year Ubuntu 26.04 did add a new step).
Yes! I used to use deadsnakes before as well. This is just my flow that I enjoy doing the most and wanted to share. The deadsnakes flow is less steps and you get the benefit of updates. So it's probably even better for most people.
I just like the flow where I know which version I'm on, and exactly the steps I took to get there. =D
To illustrate my point with an example: Python packaging has a lot of cargo cult because the overwhelming majority of Python programmers don't understand what needs to be done to accomplish the task of packaging their code and don't know how to verify that what they wanted to do was actually done.
One such ironically stupid and ubiquitous (but relatively harmless) detail is this: Python programmers are told to use pyproject.toml in order to, beside other things, configure the build of their distributable binary package (if the project intends to have one). It is very common to have [dev] and [test] sections in this sort of configuration, which Programmers might believe to describe their development or testing requirements... however, instead, they describe feature dependencies. Something completely different from what their authors intended.
The reason this happens is that it makes it easy to install development and/or testing dependencies by typing eg. "pip install -e '.[dev]'". And nobody looks into the resulting package metadata, where all these dependencies are listed in their respective feature sections...
This is not the only stupid thing that goes into the generated package metadata. There's the useless "Dynamic" metadata field declaration that serves absolutely no purpose, but is added by the build tools (and nobody ever examines the output). I've found that a lot of even very popular Python packages never look into the output of their builds and package a lot of useless garbage with whatever code they distribute (eg. for a long time NumPy were packaging their unit tests together with the rest of their code...). Tools like uv and pipenv certainly help with obfuscation and, subsequently, worsening the quality of the output.
If you use uv or pipenv, not only do you not prevent this problem, you actually make it a lot harder to get rid of it, because now you've added another tool to your toolchain that can't be used to do the right thing and pushes you even harder in the direction of doing the wrong thing.
Just wanted to share for anyone and show that it has certainly gotten easier over the years (though this year Ubuntu 26.04 did add a new step).
You can add this PPA (personal package archive) to your Ubuntu install. Then you can use apt to do the install of the newer version.
https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa
Just another alternative method, and potentially easier/faster.
I just like the flow where I know which version I'm on, and exactly the steps I took to get there. =D