Hey everyone! I'm working on a Python application that's organized into modules, but I haven't set it up as a proper package yet. I'm curious about where to install these modules on different Linux distributions.
On Debian 12, I can install my modules under "/usr/lib/python3/dist-packages/appname/". However, on EL10 (specifically AlmaLinux 10), I have the option to install them either in "/usr/lib/python3.12/site-packages/appname/" or "/usr/lib64/python3.12/site-packages/appname/".
Here are my questions:
1. Why doesn't Debian have a "/usr/lib64" directory for Python modules?
2. When should I use "/usr/lib/pythonx.x" versus "/usr/lib64/pythonx.x" on EL systems?
Thanks for your help!
3 Answers
It's generally best not to install Python modules globally as it can create conflicts. Using virtual environments (venvs) can help keep things tidy and avoid issues with global dependencies. It's a more organized approach!
The reason Debian only has "/usr/lib" instead of "/usr/lib64" is due to its unique approach to multi-architecture support. In Fedora and its derivatives, there's a distinction because of how they handle binaries. Debian's setup is more complex—it doesn't separate modules based on architecture as Fedora does.
As for EL systems, if you're building an RPM package, stick to using the pyproject macros. If you're not packaging, avoid installing into system directories. PIP will warn you against it, and it's best practice to install your modules in a virtual environment.
Thanks for clarifying that, Gordon!
The absence of "/usr/lib64" in Debian is rooted in historical practices when both 32-bit and 64-bit libraries coexisted. Debian pioneered a change in how multi-arch is handled a long time ago. I don't use AlmaLinux, but I'd guess that one of those directories could be a symlink to the other for backward compatibility reasons.
They're actually separate directories in Python for different module types; there's no symlink trick in this case!
Thanks for the tip! But why exactly is it considered a mess?