You are not logged in.
I personally really dislike this change. Pipx is a great tool, but not every python package is a complete CLI tool, you cant really install libraries with pipx... and not every Pypi package is in the repo or the AUR. Resolving that is a nightmare when pip and arch mix packages when your needed package only exists on Pypi (from both user and system). I installed python-pillow via pacman and Python cant even resolve where it is.
So this leaves creating Venv's in random directories and having to track them to call them from outside of that environment. I like to use Python as a secondary scripting language to something like Bash. I generally write them, put them in the same directory somewhere, throw a shebang at the top and run them as if they were any regular system tool. So now I have to write a custom wrapper script just to achieve this behavior while avoiding conflicts with packages.
I'm glad more people are just using Pipx and it's nice that this adds a lot of resilience for a user who's not using python that much but this has become somewhat of a nightmare for me. I'm trying to find a better solution then just using a crap load of virtual environments all over the place. So far I've just been using Go-lang since it auto-magically handles these dependencies and the binaries run anywhere.
Offline
So this leaves creating Venv's in random directories and having to track them to call them from outside of that environment. I like to use Python as a secondary scripting language to something like Bash. I generally write them, put them in the same directory somewhere, throw a shebang at the top and run them as if they were any regular system tool. So now I have to write a custom wrapper script just to achieve this behavior while avoiding conflicts with packages.
I create very many such utility "scripts" as well and don't get what you are doing that is unique. If a utility requires a package then 99% of them are packaged in the Arch or the AUR so just pacman install that system package and put your utility in your $PATH, e.g. `~/.local/bin/`. If it is a more sophisticated utility that requires some obscure packages not in Arch or the AUR, then whip up a tiny pyproject.toml (or setup.py if you are old school) in your app source dir which defines those dependencies etc, and then `pipx install .` I often do `pipx install -e .` instead to be able to conveniently edit the installed code if I am still developing it. Again, I used to do those two commands with `pip install --user` but now (since Arch imposed the externally managed environment lockout) I simply use `pipx install`.
Offline
I installed python-pillow via pacman and Python cant even resolve where it is.
BTW, not sure what error you mean here but you can give your venvs access to 3rd party pacman (i.e. system) installed packages by adding `--system-site-packages` to your pipx install line, just like you can on `python -m venv`.
Last edited by bulletmark (2023-09-17 00:04:14)
Offline
How would one use pip with CONDA? I am no longer able to pip install -r requirements.txt from within a CONDA environment without running into this error.
That's because your conda env doesn't have pip, so it's using the system-wide one. just do `conda install pip` and you should be good to go.
(Just ran into this issue and eventually figured it out on my own and wanted to post this somewhere in case others need)
Last edited by samm0 (2023-10-02 21:23:22)
Offline
First of all, thanks for sharing the option to add `break-system-packages true` to ~/.config/pip, which does seem like the best approach for those who prefer to continue installing (python) system packages using pip.
I was / am somewhat surprised to see such a change being rolled-out to Archlinux, considering Archlinux typically targets users that know what they do, and do not want to be "bossed around" / protected from doing stupid things. Truth be told, I am even somewhat irritated about that.
For my personal setup, I have been doing python development for over five years on my machine, and have thus far always installed dependencies as system package / system-wide (I tend to always run everything against "latest-and-greatest" dependencies / update frequently). I never saw issues (except occasional changes I had to do for my own code from incompatible upgrades of used dependencies; which I consider okay and part of the task of software maintenance).
Offline