On 30 Jan 2014 23:26, "Paul Moore" <p.f.mo...@gmail.com> wrote: > > On 30 January 2014 12:29, Nick Coghlan <ncogh...@gmail.com> wrote: > > I actually think this is a useful thing to experiment with, I'm just > > not sure distlib is the best place for that experiment. With > > appropriately secure tempfile handling and the right sys.path (and > > module __path__) manipulation it's not obviously *impossible* to > > handle C extensions at arbitrary positions in the module namespace > > this way, just difficult. zipimport itself is a bad place to > > experiment though, since not only is it currently a complex ball of C > > code, but adding such a feature without clear evidence of robust > > support in a third party project would be irresponsible. > > I just sent a long message that essentially gave a chunk of history > and suggested a similar thing - an "enhanced zipimport" module to > experiment with solutions in this space. With importlib available, an > experimental implementation shouldn't even be too hard. > > The only difference is that I see very little reason why such a > solution can't apply to all zipfiles, and not just wheels.
The advantage of wheels over plain zipfiles for this use case is the structured metadata. distlib.mount doesn't try to guess the package structure for the extensions, you have to provide an EXTENSIONS file in the metadata that explains what C extensions are present and how they should map into the module namespace. Cheers, Nick. > Paul
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
