17

I updated my Ubuntu from 22.04 to 24.04 Previously python 3.10 was getting used Now the default version is python3.12

  1. Python 3.12 seems to call for virtual environment usage, Have been going through some documentation and forums, but was thinking if it is better to go back to python3.10
  2. Would you recommend update-alternative where I can have both versions?
[sudo] password for meena: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package python3.10 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'python3.10' has no installation candidate

Meenohara
  • 283
  • 6
    Python 3.12 (and 3.11 as well I believe) insists on using a virtual environment because not doing so is extremely risky. Dependency management for Python is almost as bad as it is for C/C++, except that with Python if something goes wrong it breaks your system, not just your ability to build software. It sounds like you’ve never actually worked with venvs properly before, so I would suggest looking into https://python-poetry.org/, it handles all the tricky stuff for you and does a much better job than the default Python tooling at providing reproducible environments to work with. – Austin Hemmelgarn Oct 17 '24 at 20:50
  • 2
    Have you looked at solutions involving third-party repositories? – Hermann Oct 18 '24 at 00:05
  • @AustinHemmelgarn It's not true that dependency management for Python is almost as bad as for C/C++, and it's not true that if something goes wrong with Python it breaks your system. Yes, if something goes wrong with the system installation of Python it will break your system, but that's not a reflection on Python in general - by analogy, if something goes wrong with the system installation of libc it breaks your system, but we don't use that as justification to say that if something goes wrong with C it breaks your system. – David Z Oct 18 '24 at 07:11
  • @Hermann if you put that as an answer, you'll get my upvote. – James_pic Oct 18 '24 at 09:00
  • 4
    You'll have to deal with this sooner or later, so why not now? – HolyBlackCat Oct 18 '24 at 09:34
  • 3
    @DavidZ Compared to stuff like Elixir, Node.JS, Go, or Rust, Python without usage of venvs is only marginally better than C/C++, and it only manages to be better because they provide an actual package manager, not because it somehow solves the issues of package version mismatches in dependency trees. You still have all the issues of needing all your dependencies to be compatible with each other or handle their versioning themselves, and you still have almost all the issues of not having proper namespacing of dependencies. – Austin Hemmelgarn Oct 18 '24 at 11:10
  • @AustinHemmelgarn No not familiar with virtual environments, I referred an online resource and also created a venv, but deleted before I came here to ask this – Meenohara Oct 18 '24 at 12:42
  • @Hermann I am looking at the link you shared have been having a hectic day, And because this is laptop given at work I think a lot before doing anything – Meenohara Oct 18 '24 at 12:43
  • @HolyBlackCat yes at some point I have to Learning more now – Meenohara Oct 18 '24 at 12:44
  • @AustinHemmelgarn Python without usage of venvs is mostly irrelevant these days, is not what I was talking about, and is not a fair comparison anyway because, among the tools you mentioned, all of them that I know of have some equivalent of virtual environments which improves their dependency management experience. If you want to dump a bunch of different packages into a single Python environment without using a virtual environment, you're inviting these problems on yourself. (I would suggest that if you want to continue this discussion, it should probably happen in chat) – David Z Oct 18 '24 at 18:11
  • 1
    going back is a bad idea. Hundreds of PCs in my company had the version reverted and then lots of issues happen, like the inability to use apt_pkg which means no software install or update. It's tricky to fix, especially for lots of computers – phuclv Oct 19 '24 at 04:26

6 Answers6

15

Python 3.12 seems to call for virtual environment usage, Have been going through some documentation and forums, but was thinking if it is better to go back to python3.10

No, it's not better to go back to Python 3.10.

Or more precisely, it's not better to change the system installation of Python back to 3.10. Your system is built in a way that it expects to have Python 3.12 available, and if you remove it, various things will stop working.

There are two changes you can and probably should make to your Python usage:

  1. Virtual environments are now a recommended practice for all versions of Python, so you should start using them. There are numerous tools that you can use to create and manage virtual environments; for example, I particularly recommend pipx for installing Python applications, i.e. anything you intend to run, but not use in your own code. If you're going to be writing your own Python code, on the other hand, consider something like hatch (my favorite), pdm, flit, or poetry (which is a little less polished than the others; it slightly predates some of the modern standards in Python development). You might also consider pipenv, which is a simpler tool that just creates a virtual environment and manages the list of packages installed in it, without the development project features the others have.

    You can also create virtual environments manually using the venv module which is built into the Python standard library (python -m venv <path>), or virtualenv which is a slightly more sophisticated version of the same thing. Each of these tools has its own unique workflow so you can try them and see what you like.

  2. If you need access to different versions of Python other than 3.12, I'd suggest installing them "manually", not using apt. Perhaps the easiest way to do this is with something like pyenv, which gives you a fairly simple tool that can install, upgrade, and uninstall many different versions of Python without touching the one used by your system. After you install the version you need, you can then use it to create virtual environments, or you can have your tool of choice use it to create virtual environments.

There are other tools like rye and uv (now in the process of merging... sort of?) which try to do all of the above things - they will let you create and manage virtual environments, and also let you install and manage versions of Python. Feel free to give those a try if that sounds useful.

David Z
  • 11,035
  • Thank you Have one doubt about these virtual environments. Somewhere I had read they can be configured sepaartely for different projects or have a common one, unable to find now What would you recommend? Have one common virtual env or have separate venvs? – Meenohara Oct 18 '24 at 12:39
  • Separate venvs, for sure. venvs are relatively lightweight, so you don't have to worry about creating a new one whenever you need it. – David Z Oct 18 '24 at 18:12
8

Don't change the default python version. That will destroy Ubuntu.

Instead, use a virtual environment with Miniforge.

Download the 64 installer for linux, as described here.

Now install it.

curl -L -O "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"
bash Miniforge3-$(uname)-$(uname -m).sh

Now create a virtual env with python3.10

conda create -n myenv python=3.10

Activate this environment with

conda activate myenv

Now run python3, and it should be python3.10.

6

I've found that pyenv is more comfortable to use than other tools like anaconda.

You can find the installation instructions here: https://github.com/pyenv/pyenv#automatic-installer

After installing it, using it as simple as running

pyenv install 3.10

to install a given python version.

If you want to use python version globally, you can set it with

pyenv global 3.10

and if you want to set it only on a project, you can do so with:

pyenv local 3.10

This will create a .python-version file containing the version, and pyenv will automatically run that version when you run python in that directory. This is useful when you're working on various projects that require different python versions, which can happen often in a professional setting or with certain OSS projects.

Do keep in mind that this gives each python version a virtualenv, and that packages you installed on system python, even if they were on the same version at the time, will not be accessible.

ave
  • 331
6

Here's how you use Python and its packages, in order of my preference:

1. Use system Python and system packages

On Ubuntu 24.04, that means Python 3.12. You install required packages through apt (e.g. apt install python3-numpy or apt install python3-django).

  • Lowest barrier to entry
  • Security updates for all packages are managed by your distribution vendor.
  • You only get access to Python packages that your distribution offers, at whatever version they provide.

2. Use system Python and Virtual Environment

Again, for you that means Python 3.12. Set up a Virtualenv per project and install packages there (e.g. virtualenv venv; source venv/bin/activate; pip install whatever).

  • Slightly more work, but not too much.
  • You get full control over what packages you have access to, and their versions. These can differ from one project to another.
  • Keeping the packages in the Venv up to date with security updates becomes your responsibility.

3. Use pyenv or something like anaconda

Unlike the previous solutions, this allows you to get different Python versions. Try to avoid this, if you can. If software works on Python 3.10 but breaks on Python 3.12, the better approach is to fix the software.

Never use pip as user outside a venv (or pyenv or anaconda, or...)

This installs software "globally" under your user account. It becomes hard to manage, and you don't get isolation between projects.

NEVER use pip as root outside a venv (or ...)

Same problems as above, but bigger. May break your system.

marcelm
  • 949
  • 1
    Well summarized :-) but I think it would help to make it a bit more clear that there are some things you can't do with option 1 (system packages only). Particularly if you're a Python developer, but even people who are not may sometimes want to install Python programs that don't have packages available from apt. – David Z Oct 20 '24 at 00:02
  • 1
    @DavidZ That was mentioned as "You only get access to packages in your distribution, at whatever version they offer." I rephrased it a bit to be clearer. – marcelm Oct 20 '24 at 09:05
  • 1
    Ah, sorry I must have overlooked it. I was thinking it's worth really emphasizing because it's a pretty big restriction on what you can do with that option, but it's your call of course. It's a good answer either way. – David Z Oct 21 '24 at 04:40
  • @marcelm Right now I am have set up venv for only one project Do you recommend a common venv or individual ones for each project? – Meenohara Oct 29 '24 at 06:13
  • @marcelm what about deleting the environment? Any caution or right way of doing it? – Meenohara Oct 29 '24 at 09:03
  • I'd recommend a venv per project. For removing a venv, you can just delete the directory. Perhaps use deactivate first so your shell doesn't try to use that venv anymore. – marcelm Oct 29 '24 at 11:15
  • Changing default python and installing with pip everything as root seems to no always explode Ubuntu. But then, dep convolution kicks in and it's very hard to keep every python project to run. – PeterM Nov 28 '24 at 22:25
1

Just because I didn't see anyone mentioning docker:

docker run -it --rm python:3.10

If you don't have docker installed:

sudo apt install docker.io

This executes python in the version you specify in the tag. You can pass in any version, that it will work. Way quicker to setup than having to install different versions and has a better isolation from the rest of your OS. If you need to run files inside your docker container, use the -v option to mount your filesystem to the containers' filesystem.

Of course, the utility of this solution depends highly on your use case. If you want to read more about docker, see its documentation: https://docs.docker.com/

-4

Follow below steps. This works for me.

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
apt-get install python3.10
unlink /usr/bin/python3
ln -s /usr/bin/python3.10 /usr/bin/python3
  • 1
    This is dangerous. It might seem to work, but any number of utilities depend on the system version of Python, and can break because of this. Do NOT change /usr/bin/python3. – muru Jun 13 '25 at 07:53
  • 1
    NEVER change the default Python of an Ubuntu installation! Some system components rely and depend on the standard Python version, which is 3.12 for Ubuntu 24.04. Changing the default Python to a different one, especially an older one, may lead to an unexpected behaviour of the system and worst case a non-function system. The first three steps are OK, but do not use unlink and ln. Instead, better call Python 3.10 explicitly with python3.10. – noisefloor Jun 13 '25 at 10:34