pipenv 2022.8.5.13 introduced an issue with platformdirs #5254
Comments
|
This is an interesting one @OOPMan -- I was able to reproduce it, but when I passed the verbose argument, I saw in the output that The only way I was able to get it to work was by first uninstalling I am not sure why it would be preferring what is in site-packages and not adding it the virtualenv. I looked over the changes from the two versions and it doesn't stand out to me yet what would be causing it. |
matteius
added
Type: Bug 🐛
matteius
added
the
PR: awaiting-review
|
@matteius I will probably only be able to take a look at it tomorrow on my side, but will give it a go |
|
I'm experiencing the same issue on Ubuntu 22.04. It doesn't seem limited to platformdirs. I also notices it affects certifi etc. Downgraded to v2022.8.5 and can confirm the issue is not present there. |
|
We are experiencing the exact same issue with a different package. we have also retraced to the same root cause and came up with the mentioned mitigations described by all of the above |
|
@ajvogel @lender-hunters Please try the proposed fix branch and provide feedback on if it resolves the issue. |
|
@matteius it did not solve it for me unfortunately. haven't mentioned it yet but I actually use |
|
@lender-hunters Are you sure you tried the branch, and if so how did you install it? When you run |
|
I pushed a new commit to that branch to address the failing test. |
|
The branch doesn't work for me either. I want to point out that it appears to be finding the correct python (the python inside the venv) but the pip command is different. Version 2022.8.14 (with or without your patch): Version 2022.8.5: |
|
@chrahunt The change to use the vendor'd pip was intentional -- I would think that since the python being invoked is from the virtualenv that it would prefer to install the dependencies to the virtualenv. For my testing I found the branch to resolve the issue, as I have certifi installed in my site-packages as well as platformdirs, and pipenv created my virtualenv with the requested dependencies: But then again, I am getting that behavior on the main branch now too :-/ |
|
@chruss2 I just pushed a change to that branch to |
|
Ok if I install pipenv from pip then I can reproduce the issue: So beyond noting the difference in behavior is really weird, my question now is for those who have tried my branch, how did you install it? I'd like to try installing it that way so I can think more about what the difference could be. |
|
Ok I found I could reproduce it with Checking my prior commit to be sure: I believe now though the latest version of the branch is solving the issue at this time. If I could get confirmation from someone else that you agree, I will feel good about getting this patched up in a new release. |
|
Yes, the latest commit works now. 👍 BTW, I was curious why this was happening, so I looked into how pip is vendored. The vendoring is adding line 29 to main.py: This line is needed in order to import pipenv.patched.pip._internal.cli.main, but also affects how packages are installed. I figured I'd mention this, since changing sys.path may affect pip in other areas of the code too. |
|
@chruss2 This is really interesting what you point out, I have wondered about that post pip import patch before and tried removing it without success. I do wonder if its necessary that it insert the path to be first, but probably that is safer to ensure that pipenv imported is the one that is being invoked. The tests do pass however if I modify the line to append (instead of insert to front) the path instead -- I am not sure if that would change the outcome of any of this original issue though. Just want to call out for this pain point/bump in the road, I had several motivations for making pipenv rely exclusively on the vendor'd pip:
That being said I wanted to head off any issues as soon as possible, because it was hard to be certain what kinds of side effects would be brought about. That is why I opted for a Saturday release and to be available this weekend for fixing any issues not caught by the test runners. |
|
|
Issue description
We have a job in our CI pipeline to uses
pipenvto set up an environment withblackand then run said tool. Our CI job for this in Gitlab-CI is extremely simple:Unfortunately it seems like the release of pipenv 2022.8.5.13 introduced some issue with the
platformdirspackage.The following is a log of a CI successful run of our job from August 12th 2022:
The following is a log of a CI failed run of our job from August 13th 2022:
I am pretty sure that this issue is caused by some change between
pipenv2022.8.5 and 2022.8.5.13 for the following reasons:pipenv(Which, you will note from the CI job details was not version locked)pipenvinstalled was locked to 2022.8.5 corrected the issueExpected result
pipenvshould installplatformdirscorrectly into the environmentActual result
pipenvseems to fail to installplatformdirsinto the enviromentSteps to replicate
This should be replicable using the steps in the CI job listed above along with any old random codebase
The text was updated successfully, but these errors were encountered: