 |
 |
- so, would it means that on Debian derivatives, binary python packages are not functional unless one, after
pip install --usermodify by hand the environment?
how the others (rhel/fedora) can make it work and cannot be replicated by the pip install process?
This has a complicated answer, that I don't know if I can give a good summary to beyond showing it (as I think this also gets down into the fundamental differences about where Debian and RHEL place things), but this comes down to how different OS define and treat the user site. I would also highly recommend reading the pip docs segment on user installs which highlights this further.
In general I personally recommend avoiding --user installs and just setting up a default virtual environment (e.g. create a virtual environment and then activate it in your shell's profile or in a more specific case add its bin to PATH so it will get activated by default). It also makes it far easier to reason about what is actually happening as you can be assured that you're using the Python you think you are.
- i see that i already answered above :)
Hm. This is strange given that you have sufficient versions, yet they are not being found. My suggestion is that you replicate this error in a Docker build in ubuntu:20.04 or in an interactive session in ubuntu:20.04 (maybe where you are not root at pip install time so that the --user flags will actually matter?) and that there will be an easy to reason about environment.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1