-
-
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
Expand/restore vendoring support for zip archives #4641
Comments
I've confirmed the issue can be replicated simply:
|
I've confirmed that the path is being set correctly.
According to the zipimport docs:
I've found that even explicitly setting that path doesn't allow the vendored imports to be imported:
It seems to be a bug in zipimporter and not Setuptools. |
This is duplicate of #4640 |
Interestingly, I'm unable to replicate the behavior using a simple archive:
I seem to recall something recently about zipimporter having trouble with zip files whose directories don't have explicit entries. Let's see if that's a factor. |
I've confirmed that the setuptools wheel doesn't have directory entries:
I've found one reference indicating that zipimport can't load such archives. @gaborbernat Can you confirm that the archives used in virtualenv have the same issue (no explicit directory entries)? |
It's a known bug in Python (python/cpython#59110), fixed in Python 3.14 apparently. I've been using Python 3.13.0rc1+. Prior to that change, Python considered zip files with no explicit directories to be "broken". |
Be that so, the change to the simplified vendoring is breaking existing behavior :D and 3.13 EOL is very far :D |
Downloading the zip archive from GitHub, which has the explicit directories, doesn't encounter the issue:
The workarounds/solutions are several:
I don't think there's anything Setuptools can or should do here. Reviving the re-write vendoring technique is not viable. |
If you are not controlling creating the archive, this will not work.
You already highlighted why this might not work.
Not really a solution for at least another year for apps. Not a solution at all until another 6 for libraries.
This can work but means no bug fixes or feature additions for people using this feature. So none of the workarounds is an all around solution IMHO. |
I'm not aware of any options that Setuptools could employ to overcome this situation. If someone else has suggestions, I'm open to ideas. |
The previous vendoring solution did not manifest this issue, but I understand you do not want to back. |
In #4457 (comment)_, @gaborbernat reported that the simplified vendoring strategy means vendored dependencies are no longer working for zipimporter archives.
Although the best recommended solution is for downstream integrators to incorporate the dependencies (
setuptools[core]
) naturally, it would be nice if the vendoring could continue to work until dependencies can be fully declared naturally (e.g. undersetuptools
).The text was updated successfully, but these errors were encountered: