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@sazhin.us> wrote:
On Thu, Jan 30, 2014 at 2:32 PM, Daniel Holth <dholth@gmail.com> wrote:
On Thu, Jan 30, 2014 at 2:15 PM, Evgeny Sazhin <eugene@sazhin.us> wrote:
On Thu, Jan 30, 2014 at 1:24 PM, Daniel Holth <dholth@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.