[Python-Dev] Safely importing zip files with C extensions

[Daniel Holth]

Jim Fulton is right that weird failures are a characteristic of zipped
eggs, so one of the #1 requests for setuptools is how to prohibit
zipping from ever happening. This is an important reason why wheel is
billed as an installation format -- fewer users with pitchforks. It's
very cool that it works though. Debugging is slightly easier than it
was in the old days because pdb can now read the source code from the
zip.

An unzipped wheel as a directory with the same name as the wheel would
be a more reliable solution that might be interesting to work with. It
would work the same as egg unless you had important files in the
.data/ (currently mostly used for console scripts and include files)
directory. However it was always confusing to have more than one kind
(zipped, unzipped) of egg.

On Wed, Mar 27, 2013 at 4:41 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Amaury Forgeot d'Arc <amauryfa <at> gmail.com> writes:
>
>
>> Better: just put the wheel path to sys.path
> sys.path.append('/tmp/simplejson-3.1.2-cp27-none-linux_x86_64.whl')
>> and let a sys.path_hook entry do the job.
>
> That's what the mount() actually does - adds the wheel to a registry that an
> import hook uses. You also need a place to check that the wheel being mounted
> is compatible with the Python doing the mounting - I'm not sure whether what
> the import hook should do if e.g. there is a compatibility problem with the
> wheel (e.g. is it clear that it should always raise an ImportError? Or ignore
> the wheel - seems wrong? Or do something else?)
>
> Regards,
>
> Vinay Sajip
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com