On Thu, Jan 30, 2014 at 2:32 PM, Daniel Holth <dho...@gmail.com> wrote: > On Thu, Jan 30, 2014 at 2:15 PM, Evgeny Sazhin <eug...@sazhin.us> wrote: >> On Thu, Jan 30, 2014 at 1:24 PM, Daniel Holth <dho...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
