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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
