You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, this is a slick plugin for PDM-managed projects with pure-Python dependencies -- thanks!
Is your feature request related to a problem? Please describe.
Is is clear from the caveats section of the zipapp docs that Python cannot load a native/C extension from a zipapp. Some of the bugs logged against this project are caused by that (e.g. #11, #33) and have been closed as "not planned".
Describe the solution you'd like
The referenced zipapp caveats section also suggests how to ship a zipapp dependent on a C extension:
"exclude that dependency from the zipfile, and ... ship it alongside your zipfile" and
"include the directory containing the unzipped module in sys.path"
It would be nice if there were an easy way to generate output like that. For example, if I'm building myapp.pyz and I have a dependency on the "cryptography" library (among others), then I end up with:
myapp.pyz - My code and all of the zip safe dependencies
myapp-lib\ - A directory with all of the non-zip safe stuff installed, like cryptography
There would perhaps be an entrypoint shim that would insert myapp-lib\ into sys.path before calling the user-specified entrypoint.
Then I'd distribute both the zip file and the associated directory.
Describe alternatives you've considered
Do some kind of yet-to-be-determined pre and/or post processing external to pdm-packer to get to the desired output (suggestions on this welcome).
Use zipapps, a project that helps build zipapps with extensions, but which isn't as nicely integrated with PDM.
Use PEX or shiv or something that is zipapp-ish.
Additional context
The zipapps project mentioned above actually includes packages with native extensions in the zip file and extracts them at runtime and adjusts sys.path. It can optionally do that automatically by looking for dependencies having .pyd or .so files at build time. For my situation, having them separate at build-time would be better, but I could see the extract thing being useful too.
Finally, a little feedback on the README.
I wasn't sure whether external dependencies would be included in the zip file produced by pdm-packer at all. Maybe the brief description could be amended to say "A PDM plugin that packs your packages and their dependencies into a zipapp".
Having tried it and discovering that it did include dependencies I saw the caveat "If the result zipapp contains binaries..." which made me think that it might also support C extensions, but only for a single platform.
If this proposal is out-of-scope, that would make an excellent additional caveat -- that all dependencies must be pure-Python.
The text was updated successfully, but these errors were encountered:
First, this is a slick plugin for PDM-managed projects with pure-Python dependencies -- thanks!
Is your feature request related to a problem? Please describe.
Is is clear from the caveats section of the zipapp docs that Python cannot load a native/C extension from a zipapp. Some of the bugs logged against this project are caused by that (e.g. #11, #33) and have been closed as "not planned".
Describe the solution you'd like
The referenced zipapp caveats section also suggests how to ship a zipapp dependent on a C extension:
It would be nice if there were an easy way to generate output like that. For example, if I'm building
myapp.pyz
and I have a dependency on the "cryptography" library (among others), then I end up with:myapp.pyz - My code and all of the zip safe dependencies
myapp-lib\ - A directory with all of the non-zip safe stuff installed, like cryptography
There would perhaps be an entrypoint shim that would insert myapp-lib\ into sys.path before calling the user-specified entrypoint.
Then I'd distribute both the zip file and the associated directory.
Describe alternatives you've considered
Additional context
The zipapps project mentioned above actually includes packages with native extensions in the zip file and extracts them at runtime and adjusts sys.path. It can optionally do that automatically by looking for dependencies having .pyd or .so files at build time. For my situation, having them separate at build-time would be better, but I could see the extract thing being useful too.
Finally, a little feedback on the README.
The text was updated successfully, but these errors were encountered: