-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emergent test failure on pypy3: no module named zipp #2000
Comments
Running the build locally, I don't encounter the issue. |
I was able to replicate the issue with this Dockerfile:
|
Debugging deeper, I see that zipp isn't being installed as unknown:
|
I was able to replicate the issue without tox using this Dockerfile:
Doing some more troubleshooting, I've identified the proximate cause:
|
@jaraco Assuming it's not as simple as "upgrade pip in |
I've tried to address this issue with tox-dev/tox-venv#25, but there was too much pushback and I gave up. Now the issue rises again where the workaround |
With virtualenv now creating venv style environments by switching back to virtualenv you can guarantee newer pip out of box 🤷♂️(tox-venv is kinda absolute with virtualenv 20, not?) |
It isn't. There's no opportunity to upgrade pip as tox is managing the environment creation and because it's the bootstrap environment, so doesn't get the benefit of
Yes, perhaps. I was really hoping to be able to rely on the stdlib implementation. My understanding was that tox was going to integrate tox-venv as the default implementation, so I wanted to adopt that. It will take a lot of work to unravel the work it took to get venv working. I'm going to defer this effort until I have confidence that venv/tox-venv is superseded. Plus, setuptools is currently pinned against virtualenv 20 because of pypa/virtualenv#1638, so that's a non-starter for now. Given the limited scope of this issue, I'm just going to mark the tests as expected failures in Travis until someone has the time to develop a more robust solution. |
I think you misunderstood this. The plan here was to create venv style environments instead of old virtualenv styles. The solution here was and is to use virtualenv 20, not to provide support for venv. venv is a standard library module, and out of our control; so relying on it besides gives you some kind of venv is asking for trouble (as you found out here). This has been achieved and there are no future changes planned on the environment creation side.
That issue as I understand is supporting a feature that was implemented by exploiting the internal workings of virtualenv. The fix there will be to fix |
Even in maint/44.x, tests are failing to run on pypy3 with this error:
The text was updated successfully, but these errors were encountered: