[Distutils] wheels on sys.path clarification (reboot)

[Daniel Holth]

Wow, it really can install from a directory-named-like-a-wheel with
the --no-index flag passed. I'm sad to say that is totally
unintentional, but bizarrely interesting.

On Thu, Jan 30, 2014 at 2:52 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
> On Thu, Jan 30, 2014 at 2:32 PM, Daniel Holth <dholth at gmail.com> wrote:
>> On Thu, Jan 30, 2014 at 2:15 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>> On Thu, Jan 30, 2014 at 1:24 PM, Daniel Holth <dholth at gmail.com> wrote:
>>>> One thing that might be useful would be to develop the "unpacked
>>>> wheel" which is currently undefined but would be deliberately
>>>> identical to a site-packages with just one wheel extracted into it.
>>>> You wouldn't have to argue or worry about the zip issue.
>>>>
>>>> I like the way npm puts everything into a directory
>>>> ~/.npm/packagename/0.4.2/ ... for example, gem is similar. If you
>>>> really wanted to go to town you could figure out how to do virtualenvs
>>>> with hardlinks or reflinks instead of copies (conda can).
>>>>
>>>> But as has been repeated you won't find robust support for this in the
>>>> existing code.
>>>>
>>>
>>> I just tested it - it works! Yeah!
>>>
>>> I put an unzipped wheel of my API project into a local wheelhouse -
>>> pip was able to install from it into my virt env for the client
>>> project.
>>> Then i created a wheel with __main__.py for the client project and put
>>> an unzipped version in wheelhouse.
>>>
>>> After that i issued:
>>> PYTHONPATH=~/wheelhouse/projectAPI.whl; python ~/wheelhouse/projectClient.whl
>>>
>>> It worked!
>>>
>>> Is this workflow OK to rely on in future?
>>>
>>> Thanks,
>>> Eugene
>>
>> The only request is that you don't name the directory ".whl" because
>> that is a little bit confusing.
>>
>> "Directories with only one package installed into them" will continue to work.
>
>
> pip can't find the distribution then - so it must have the name
> totally matching wheel spec, i guess.