[Distutils] Importable wheels using distlib/distil

[Jim Fulton]

On Thu, Mar 28, 2013 at 12:02 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Jim Fulton <jim <at> zope.com> writes:
>
>
>> >> It would be far better IMO to just unzip the wheel and put that in
>> >> your path.  (I'm hoping that wheels used this way are a suitable
>> >> replacement for eggs.)
>> >
>> > Well that's tantamount to installing the wheel,
>>
>> Not really. If you just unzip the wheel and add it to your path,
>> you can stop using it by just removing from your path. If you
>> install the wheel, it's contents will be poured into site-packages
>> (and other places).    It's much heavier than just adding the
>> wheel (zipped or unzipped) to your path.
>>
> [snip]
>> by adding (unzipped) eggs to sys.path.  Various plugin
>> systems (including buildout itself with extensions and recipes)
>> do this dynamically at run time. It's very useful.
>
> Thanks for the feedback.

Thanks for trying to provide a useful feature. I hope my comments
aren't too much of a downer.

> How about if I change mount()/unmount() to:
>
>     def mount(self, append=False, destdir=None):
>         """
>         Unzip the wheel's contents to the specified directory, or to
>         a temporary directory if destdir is None. Add this directory to
>         sys.path, either appending or prepending according to whether
>         append is True or False.
>
>         Before doing this, check that the wheel is compatible with the
>         Python making the call to mount().
>
>         If successful, this makes the contents of the wheel's root directory
>         - both Python packages and C extensions - importable via normal Python
>         import mechanisms.
>         """
>
>     def unmount(self):
>         """
>         Remove the directory that was used for mounting from sys.path,
>         thus making the wheel's code no longer importable.
>
>         Return this directory. Note that the caller is responsible for
>         deleting this directory and its contents, which might not be
>         possible - e.g. in Windows, if a shared library has been
>         imported and is linked to the running Python process, there will be
>         an open handle to the shared library which will prevent its deletion.
>         """

I'm not sure which users or use cases you're trying to serve here, so
I'm not sure what to think of this.

For buildout users, buildout would download and extract the wheel the
first time it's used and keep it in a cache and then add it to a path
at script generation time.

For buildout's own uses (extensions and recipes) it would simply add
the extracted wheel's location to sys.path at run time (downloading
and extracting it first if necessary).

So the win for buildout and it's users is to be able to have extracted
(but not "installed" wheels) around to be mixed and matched either for
script generation or run-time use.

If I wasn't using buildout, I kinda doubt I'd want to use something
like this rather than just installing wheels with pip.

Jim

P.S. I'm happy to see all the work you've done on distlib. I'm sorry
     to say I haven't had time to dig into it yet. I assume that
     buildout 3 will be based on it at some point.

--
Jim Fulton
http://www.linkedin.com/in/jimfulton