... 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.
]]>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.
]]>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.
]]>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.
]]>. 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.
]]>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.
]]>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.
]]>I personally avoid cloning github repositories and running python setup.py install for installing anything. But we are happily doing that through aur PKGBUILDs.
]]>