You are not logged in.
Pages: 1
I need some advice on how to manage Python installations and projects on Arch Linux. I will describe the workflow I had until now on my Mac and Arch, and why it started cracking and became less than ideal. There are two main aspects of Python on the system: the system Python managed by pacman (or Apple on my Mac), used by system components and packages that use Python, and the Python I use for my own projects. Obviously, I never want to touch the system Python or install Python packages in it with pip or something similar. On the other hand, when dealing with my own projects, I want full control over Python, and possibly even install multiple Python versions.
The solution I used until now is a combination of pyenv and uv. I use pyenv to install all the Python versions I need and enable them. For example, I execute `pyenv install 3.13` and then `pyenv global 3.13`. That way, I have my own version of Python, which the `python`, `python3`, `pip`, and `pip3` commands point to, so I can play with them and install packages if I need to. I use uv for every other aspect of Python: project and virtual environment management, installing Python tools with `uv tool install` (like `pipx`), running scripts, and managing their dependencies. Since pyenv set my version of 3.13 as the global Python, uv is able to detect it and use it to create virtual environments or run Python commands. I know that uv is also capable of installing and managing different Python versions like pyenv does; however, it installs Python from their own pre-built binary distributions, which have some quirks and issues. I find it much more reliable to build Python installations from source with pyenv than using uv's pre-built distributions. Until uv allows building Python from source or to use another provider other than their own, I can't use it to manage Python installations, and pyenv remains an integral part of my Python workflow. This already causes some issues because uv can only detect its own managed Python and Python installations that are found on the PATH. This means that if I install multiple Python versions with pyenv, for example, 3.13, 3.10, and 3.9, only the version set by pyenv is detected by uv. In other words, if I set `pyenv global 3.13`, then uv can only see version 3.13 from pyenv since it's on the PATH. The other installed versions are undetected, so trying to create a project or run something that requires Python 3.10, for example, will fail until I run `pyenv global 3.10`. One solution is to put all the pyenv versions on the PATH, so uv is able to detect them all, but it doesn't sound like a good idea to pollute the PATH with so many Python versions. It's quite annoying that I have to set the correct Python version with pyenv before running uv, but I don't install many Python versions, so it didn't bother me much.
The real issue that made me realize this workflow is flawed happened a few days ago. I tried to install virt-manager, and it didn't run. After digging a bit, I found that it fails to run because it claims some Python dependencies are missing, which is strange because pacman was supposed to install all the needed Python dependencies into the system Python. I then realized that virt-manager was trying to use the Python version set by pyenv instead of the system Python. Running `pyenv global system` to reset the global version to the system Python fixed the issue. However, this means that the `python` and `pip` commands now point to the system Python, and I am unable to directly use Python for myself. I can always use `pyenv shell` to temporarily use my version, but it's still annoying. The worst part is that doing `pyenv global system` means that uv isn't able to detect any of my Python versions at all. So I have to set the global Python to be the system Python in order for pacman packages to function properly, but then I have to remember to switch it to my local versions when I want to use Python myself with uv.
I tried to look online for a better workflow that would prevent system packages from using my versions of Python accidentally, but would also allow me to use them as I wish, and prevent me from accidentally using the system Python, but I couldn't find anything satisfactory. Does anyone have suggestions on how to manage Python on Arch Linux without encountaring those issues? I would like to learn how other people interact with Python on Arch, and how their Python workflow works for them.
Offline
Rule 1: ONLY use pacman to install those Python modules you want in /usr/lib/python3.13/site-packages/, or anywhere that requires root access. I'm including AUR python packages as part of this rule, therefore only use makepkg + pacman and not an AUR helper for those AUR python packages.
Rule 2: ONLY run venv (or derivatives) as a regular (i.e. non-root) user and adopt a "project" based approach for running applications that require modules that are not covered under rule #1. Yes, this means it could be a headache of duplicate dependent library installs if you have multiple "projects" that share some of the non-global modules, but most likely those different projects need different versions of those libs anyway.
Offline
Pages: 1