Bad philosophy of installing python-[packages] as root user

amixra · 2023-03-06 10:57:23

Whenever you are installing something through AUR which depends upon some python-[package] then instead of using pip, yay uses forceful kind of installation to install directly to /usr/lib/python/site-packages/ directory which sometimes install a older version of python-[package] which conflicts with other user installations.
Apart from that it is not reliable in itself as PKGBUILDs in AUR don't mention versions of python-[package] which makes it automatically install whatever available version which could might not be satisfying the dependency at the first place.

I personally avoid cloning github repositories and running python setup.py install for installing anything. But we are happily doing that through aur PKGBUILDs.

amixra · 2023-03-06 11:01:01

why not yay uses something like pip or better pipx to install things.

Lone_Wolf · 2023-03-06 11:05:40

/usr/lib and its subdirectories like /usr/lib/python/site-packages/ are intended for systemwide installed stuff. user installations don't have any business putting things there.

Check https://wiki.archlinux.org/title/Python … management for details how archlinux deals with python applications .

EDIT : yay doesn't build packages, it calls upon the official tool for building makepkg to do that.

Last edited by Lone_Wolf (2023-03-06 11:07:36)

amixra · 2023-03-06 11:25:07

But there should be some accountable way I guess? If it allows installing famous python packages fine but why is this allowing to install libraries? Maybe that is to serve those famous python packages but problem starts arising when you are using multiple such packages which depend upon same dependency of different versions. You can't install different version manually because that would conflict with systemwide python-[package].

amixra · 2023-03-06 11:29:46

Lone_Wolf wrote:

EDIT : yay doesn't build packages, it calls upon the official tool for building makepkg to do that.

I certainly understand that and I have been using that actually for installing packages which were conflicting or not installing. For example, midi2grub needed python-mido which was throwing some errors in installing saying some errors related to metadata generation then I installed it manually through pip and commented `depends` section of midi2grub PKGBUILD and used makepkg -sif to install it.

amixra · 2023-03-06 11:33:50

One more example, awscli needs docutils<0.17 and >0.10 but pacman offers python-docutils of version 0.19 (it was preinstalled because of someother package) because that's only the available version! So even if it installs successfully you can't run it. That's why not caring about versions and making it globally available for creating conflict with other version dependency seems careless rather than "preferred way"

Last edited by amixra (2023-03-06 11:36:29)

Lone_Wolf · 2023-03-06 11:52:59

aws-cli is in repos at https://archlinux.org/packages/community/any/aws-cli/ .
If it doesn't work with the python-docutils also in repos, file a bug report .

. For example, midi2grub needed python-mido which was throwing some errors in installing saying some errors related to metadata generation then I installed it manually through pip and commented `depends` section of midi2grub PKGBUILD and used makepkg -sif to install it.

If python-mido has build errors, you should post a comment about the error on the aur page of python-mido so the maintainer can look into it.

an archlinux system has only one package manager : pacman (includes makepkg) .
Don't install systemwide stuff outside of pacman.

There are several methods to run different versions of python stuff as user without clashing with systemwide installs, use one of those if needed.

Trilby · 2023-03-06 13:18:19

You've identified real symptoms, but you're attributing them to the wrong problem:

amixra wrote:

You can't install different version manually because that would conflict with systemwide python-[package].

Don't manually install anything system-wide. You can manually install anything locally (i.e., to your home directory) but not to the root filesystem. This is the same for all software whether it is python or anything else and AUR or repo packaged.

If you are manually installing anything to the root filesystem, you will likely cause problems not just with aur packages, but with official repo packages too. Don't do that.

Last edited by Trilby (2023-03-06 13:28:22)

headkase · 2023-03-06 13:50:47

amixra wrote:

Whenever you are installing something through AUR which depends upon some python-[package] then instead of using pip, yay uses forceful kind of installation to install directly to /usr/lib/python/site-packages/ directory which sometimes install a older version of python-[package] which conflicts with other user installations.
Apart from that it is not reliable in itself as PKGBUILDs in AUR don't mention versions of python-[package] which makes it automatically install whatever available version which could might not be satisfying the dependency at the first place.
I personally avoid cloning github repositories and running python setup.py install for installing anything. But we are happily doing that through aur PKGBUILDs.

To get Python packages that aren't in the AUR or official repos, check out a virtual environment:

https://docs.python.org/3/library/venv.html

That let's you install and use packages using PIP without installing them system-wide. I use virtual environments for everything.

amixra · 2023-03-06 17:36:27

headkase wrote:

To get Python packages that aren't in the AUR or official repos, check out a virtual environment:
https://docs.python.org/3/library/venv.html
That let's you install and use packages using PIP without installing them system-wide. I use virtual environments for everything.

That's exactly what I do and I want that to happen officially too. Install inside a venv and then if really needed to be system-wide available then create symlinks for that. That's how I feel PKGBUILDs should be.

Trilby · 2023-03-06 17:42:50

amixra wrote:

... then if really needed to be system-wide ...

Packages are, by definition, installed system-wide. If you don't want a tool installed system-wide, don't use a package / PKGBUILD. And if you don't use a package / PKGBUILD, don't install it system-wide. This will prevent any of the conflicts you have referred to. The only way you can get the problems you describe is if you are installing software system-wide without using pacman.

Arch Linux

#1 2023-03-06 10:57:23

Bad philosophy of installing python-[packages] as root user

#2 2023-03-06 11:01:01

Re: Bad philosophy of installing python-[packages] as root user

#3 2023-03-06 11:05:40

Re: Bad philosophy of installing python-[packages] as root user

#4 2023-03-06 11:25:07

Re: Bad philosophy of installing python-[packages] as root user

#5 2023-03-06 11:29:46

Re: Bad philosophy of installing python-[packages] as root user

#6 2023-03-06 11:33:50

Re: Bad philosophy of installing python-[packages] as root user

#7 2023-03-06 11:52:59

Re: Bad philosophy of installing python-[packages] as root user

#8 2023-03-06 13:18:19

Re: Bad philosophy of installing python-[packages] as root user

#9 2023-03-06 13:50:47

Re: Bad philosophy of installing python-[packages] as root user

#10 2023-03-06 17:36:27

Re: Bad philosophy of installing python-[packages] as root user

#11 2023-03-06 17:42:50

Re: Bad philosophy of installing python-[packages] as root user

Board footer