Per user Python install area bin directory not in PATH when pip being run. #58
Comments
|
Confirmed that this is fixed by fixing #57. To test this, one can run: The repo being pointed at has a There are two instances of: The first is okay as that is when If the fix in #57 is made, then as expected one gets: In second case FWIW. Using a per user Python install area isn't necessarily the best idea. Some modules may not cope properly with that when being installed if they have to do special stuff. It may have been better to use a proper Python virtual environment. |
👍 exactly what I've been saying in the past... |
|
With Docker based images there is no need to be relocating the Python virtual environment like under OpenShift 2, so one will not have the problems which attempting to do that caused. I can't therefore see a good reason not to use a proper Python virtual environment now. In the meantime I need to go back and work out why one of my packages will not install properly under a per user Python installation area. |
|
@sYnfo are you still intending to work on this? |
|
@GrahamDumpleton since #57 is fixed, is this fixed, per your comment above? |
|
I presume this still isn't released in builder images actually in use by OpenShift. When trying on our new dedicated cluster I still see the original problem I had. It has: It would have used Python 3.4 variant as latest. I get the same problem with it. If however I create my own builder using: and then use it with my test application which triggers the problems then it is okay. So if it is the case that RHEL Python 2.7 builder is still old, then changes in repo which would be released later do appear to address the issue at least. |
|
The path in the current rhel python 2.7 looks like what you said it should be in #57: and my imageid matches what you're reporting from your cluster. So is there a different issue here perhaps? |
|
My test would have used Python 3.4 image, not 2.7, as I just let it grab latest. Let me check with 2.7. |
|
3.4 looks right too: |
|
Testing with 2.7 fails for me in the same way with my test. I can't get into a running container and manually do test because the RHEL images are still missing the libbss_wrapper stuff such that generate_container_user works and so it isn't possible to run pip after getting in using oc rsh. The latest master may well have worked for me, because the test would actually have fallen through to using the apxs program installed as part of httpd-devel in that image if it wasn't finding override version called mod_wsgi-apxs that my mod_wsgi-httpd package installed. I will need to go back and check again when using image created from master. Because this whole issue only arose for me when I was trying to work around absence of httpd and http-devel packages, then likely not a big drama if there is some reason that PATH not picked up correctly across packages being installed using pip. The updated PATH will still be of use in normal user case where they change the working directory, and PATH does show when using oc rsh that is no longer a relative path. I will though keep digging just a little longer to try and understand why my test still fails. I was sure that I had tested it okay some time back when I had forked the builder repo and created my own version with the change in it. |
|
After some more checking, although the PATH change was still necessary, I may be now hitting a subsequent issue. That is the fact that a quite out of date pip version is being used which behaves differently to more recent pip versions. The pip version installed in Python 2.7 image is 'pip-1.5.6'. That version is coming up to 2 years old in May. There has been 21 releases of pip since then. If I update the pip version within the running container to the latest version (8.0.2) and then do my tests then it works okay. Old pip versions will get a similar reaction as old Python versions. Users wants the latest, especially since newer versions support wheels, which can be used to speed up installation of packages. |
|
On the pip version side, I remember when we had only the Python 3.3 image the pip version was much older than 1.5.6, even +1 year older than that. We ran into a bug that was fixed from 1.5.6 onwards, and 1.5.6 was what we had packaged in RHEL, but not in SCL. In the Py3.3-centos image we still install that version using I noticed that discrepant line just recently when I was adding httpd to the Dockerfiles, and verified that all image versions are shipping with pip 1.5.6. Indeed pretty old. The question is are we going to get newer versions into centos/rhel packages, or would we allow ourselves to |
|
@rhcarvalho We cannot use anything else than what is in the SCL, so in case you need something newer, please, report a BZ for appropriate collection with the reasoning (please, also mind that we do not update all the collections for every release): https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Software%20Collections |
|
Closing via #159 |
May relate to #57, but when
pipis run to install modules, the bin directory for the per user Python install area, of${HOME}/.local/binis not in thePATH. This will cause problems whererequirements.txtforpiplists two modules which have an ordering relationship and where the latter relies on being able to find a program installed as a side effect of the first module to be installed.Therefore, in
assemblescripts, prior to:what is needed is:
This may not be necessary if the problem is due to the current working directory not being
${HOME}and as such fixing #57 would resolve the problem.The text was updated successfully, but these errors were encountered: