Publish Linux installer on

Speaking for Debian, if it installs into /usr/local/ or /opt with binaries /usr/local/bin or similar, it shouldn’t break the system.

If it does, that’s probably a bug in a system package. We strongly encourage distro packages to use a #!/usr/bin/python3 shebag, not !#/usr/bin/env python3.

We use dist-packages precisely so that a locally installed python can have site-packages in /usr/local/ without conflicting with the distro python.


I do not understand this. Doesn’t the Debian apt-installed Python have both a dist-packages and a site-packages? If I sudo /usr/bin/python3.10 -m pip install something (which I can not recall having ever done, I could try in a container) does it get installed in /usr/lib/python3/dist-packages? I thought only apt-installed packages would be installed there, isn’t that so?

Actually, it seems off-topic, so no need to answer here, I can probably figure out by myself.

1 Like


I also recommend /opt. The FHS defines that /opt is used for add-on and 3rd party application software. A PSF / Python installer can be considered add-on software.

I suggest /opt/pythonorg as a base directory with the same directory layout as /usr, /usr/local, and virtual envs. There would be a /opt/pythonorg/bin/python3.12 interpreter with code in /opt/pythonorg/lib[64]/python3.12. Users can then either add /opt/pythonorg/bin to their PATH or create virtual envs with /opt/pythonorg/bin/python3.12 -m venv venv. It might even be a good idea to mark the site-packages directory as externally managed, so users cannot mess up their installation and have to use virtual environments.


That’s a little painful for users (not being on the default PATH), but can be mitigated with tooling.

As soon as you are in a virtualenv, it’s not an issue any more.

This means doing a simple edit in .bash_profile right?

Yes, that’s all.

Its a pattern to use the web address like this /opt/org.python/whatever you might consider also doing this.

I was thinking about using the py launcher like on Windows, e.g. py -3.12 -m venv venv

1 Like

I used to build Python from source, that was over 20 years ago. The biggest problem I encountered was not Python itself, but the extensions that required shared libraries. Version incompatibility issues were popping up frequently. Several years ago I discovered conda, now I cannot imagine a life without it. I can install multiple environments with different versions of Python, all isolated from each other and from the system’s Python, which I do not touch. Installing extensions is a breeze.
Occasionally things go awry, conda fails to sort out dependencies, but then it is (almost) trivial to rebuild the failed environment from a scratch. Recently, I switched from conda to mambaforge to speed things up. I don’t need another Linux installer.


I don’t want to be totally negative about conda. It’s an important project, that makes easy to use python for scientific purposes. But the way conda install Python and packages modules is quite unorthodox, and I personally run in some problems with conda. For example, the fact that in conda pure python packages wins against machine specific ones is completely different from the behavior of pip, and, IMHO, completely wrong.

That said, I like the idea to have a simple way to install Python on Linux in /opt simply downloading it from

I don’t quite understand. Do you mean that venv inherits from the base environment? If that is so, I prefer the conda way, it gives me full isolation.
I am not against the proposal, I just do not need such capability.

I mean that if you publish on conda a py package, it gets the precedence even if you published also machine specific packages. This happens for C extensions. With pip, machine specific packages have the priority.

I’m not saying conda is not good, but it’s a very custom project, as well as the Debian python packages are very custom.