-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
zipapp virtual environment creation fails if zipapp path is symlinked #1949
Comments
Signed-off-by: Andy Neff <andy@visionsystemsinc.com>
Wouldn't this be fixed if you're using the copy method, instead of the symlink one? The symlink method cannot work if you're deleting the app-data folder from where we symlink. 🤔 ? |
@gaborbernat Are you saying that a user should have to add flags when calling the zipapp?
both fail the same |
I wonder why the copy fails, it should not, but will look into it. If you have free time to do it, and you can do it that would be even better 👍 |
Seems no longer an issue as no one reported it in 3 years. |
@gaborbernat: please reopen, I have just ran into this issue with virtualenv 20.24.0 on MacOS Catalina. (Why I'm still using Catalina is a long story.) It seems to me that it's important that the .pyz is referred to through the symlink, i.e. if I |
Please fill in a PR to fix it, we do not plan to work on this ourselves. |
Thanks for the quick reply! I have no idea where in the code the problem is, but I'll try to take a look. (For now, I worked around it by calling |
Upon investigation of the code, it seems like addibg virtualenv/src/virtualenv/util/zipapp.py Line 26 in 328f965
I'll try fixing it and PRing the fix later this week or next week. |
I'm seeing this issue too when upgrading our vpython client from Python3.8 to Python3.11 (using virtualenv@fdfec65ff031997503fb409f365ee3aeb4c2c89f)
|
I'm seeing this issue too when building electron
|
did you fix/bypass your problem ? |
#2613 merged after virtualenv-20.17.1 being released. So backporting those modifications to 20.17.1 can fix the problem. steps:
replace contents in zipapp.py
to
|
Tried #1949 (comment) solution, and re-run Thanks |
I just got this error on a fresh download of the chromium dev kit on ubuntu -- this workaround worked for me too but I had to move the |
Use realpath for virtualenv.pyz to mitigate pypa/virtualenv#1949 Change-Id: I4ddfb78bc435f9791ccae5e87cf5c0da404a110a Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5449147 Reviewed-by: Brian Ryner <bryner@google.com> Commit-Queue: Chenlin Fan <fancl@chromium.org> Auto-Submit: Chenlin Fan <fancl@chromium.org>
This reverts commit 988aaae. Reason for revert: Change is breaking luci-go to infra autoroller. https://ci.chromium.org/ui/p/infra/builders/try/infra-try-jammy-64/b8750527694180069633/overview Original change's description: > vpython: use realpath when invoking virtualenv > > Use realpath for virtualenv.pyz to mitigate pypa/virtualenv#1949 > > Change-Id: I4ddfb78bc435f9791ccae5e87cf5c0da404a110a > Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5449147 > Reviewed-by: Brian Ryner <bryner@google.com> > Commit-Queue: Chenlin Fan <fancl@chromium.org> > Auto-Submit: Chenlin Fan <fancl@chromium.org> Change-Id: I37d27f0fd80d93f722ed000985fa5b95f51c8c6d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5458911 Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Randy Maldonado <randymaldonado@google.com>
This is a reland of https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5449147 with fix for python2.7. Use realpath for virtualenv.pyz to mitigate pypa/virtualenv#1949 Change-Id: I4bf2f527d1a90577d25194e05bb2de00bc1d71ef Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5458472 Commit-Queue: Brian Ryner <bryner@google.com> Reviewed-by: Brian Ryner <bryner@google.com> Auto-Submit: Chenlin Fan <fancl@chromium.org>
Issue
On a fresh new system, trying to use the zipapp to setup a virtualenv when the pyz files is referenced by a symlink, it fails saying
KeyError: "There is no item named 'nv/create/via_global_ref/_virtualenv.py' in the archive"
But it works on my machine?
Yes, if you ever used the virtualenv (zipapp?) successfully, it creates files in
~/Library/Application Support/virtualenv
(on macOS) or~/.local/share/virtualenv/
(on Linux) and the existence of these files (unzip and wheel) makes the zipapp work. By deleting that directory, you should be able to reproduce the problem. This was first discovered on travis-ci, where the machine is new every time.Environment
Also reproduced on
Output of the virtual environment creation
Note: Notice
/virtuale
is missing from the KeyError, the exact length/private
which is the difference between the TMPDIR and the real path of the TMPDIR on macOSOn Fedora, the last line becomes:
KeyError: "There is no item named '/virtualenv/create/via_global_ref/_virtualenv.py' in the archive"
Steps to reproduce
docker run -it --rm fedora:31
mkdir -p /tmp/foo/bar
ln -s /tmp/foo/bar /tmp/foo/bar2
curl -L -o /tmp/foo/bar/virtualenv.pyz https://bootstrap.pypa.io/virtualenv/3.7/virtualenv.pyz
python3 /tmp/foo/bar2/virtualenv.pyz /tmp/foo/blah
Here are some one-liners to reproduce the error
Not all values of REAL/SYM fail. It appears if the length of the symlink path and realpath differ, it fails. If they are the exact same length, no error occurs
Fail
Does not fail
The text was updated successfully, but these errors were encountered: