<div dir="ltr">There are cases where projects do this in setup.py:<div><br></div><div><div>for scheme in INSTALL_SCHEMES.values():</div><div>    scheme['data'] = scheme['purelib']</div></div><div><br></div>
<div>e.g.  <a href="https://github.com/celery/django-celery/blob/master/setup.py#L80">https://github.com/celery/django-celery/blob/master/setup.py#L80</a></div><div><br></div><div>so for the sdist install, data ends up relative to site-packages, whereas for the whl install, it ends up relative to sys.prefix</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 11:50 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tl; dr; If you know of a project that can't be successfully installed<br>
with "pip wheel proj; pip install /path/to/the/wheel.whl" can you let<br>
me know the details?<br>
<br>
One of the longer-term goals of the introduction of wheels was to<br>
split the build and install steps for a package - specifically, in<br>
pip, to restrict "pip install" to installing from wheels, and when no<br>
wheel is available, to (transparently) run "pip wheel" on the sdist<br>
followed by "pip install on the generated wheel". During a discussion<br>
yesterday, I realised that I don't know how close we are to that goal.<br>
So I'm looking for information on packages which don't install<br>
properly from wheels at the moment. If anyone has examples of packages<br>
where replacing "pip install foo" with "pip wheel -w /tmp/xxx; pip<br>
install /tmp/xxx/*.whl" does not result in an equivalent install,<br>
could they post them here with details of how & why they fail?<br>
<br>
Things I already know about (but would like specific examples):<br>
<br>
1. Post-install steps included in setup.py. That should be covered by<br>
the support in Metadata 2.0. I'd also be interested in how much of an<br>
issue omitting the postinstall would be in practice (for instance many<br>
such steps just set up "Start Menu" type shortcuts, which are not<br>
essential for the package to be usable).<br>
2. Actually, that's the only one :-)<br>
<br>
Things that should not be a problem (but might be):<br>
<br>
1. Numpy (and the scipy stack) need better tagging facilities for<br>
wheels - but that wouldn't matter for a wheel that's built, used, then<br>
thrown away.<br>
2. Some things are complex to build - but I don't know of any cases<br>
where building a wheel is *more* complex than installing, and I don't<br>
see how it could be, in theory.<br>
3. Projects that customise setup.py so much that they aren't<br>
compatible with setuptools and bdist_wheel. Such projects are quite<br>
probably already incompatible with pip (which injects setuptools when<br>
running setup.py anyway) and so not relevant for this discussion. But<br>
if any do work with "pip install" but not "pip wheel", I'd like to<br>
hear about them.<br>
<br>
Thanks in advance for any information.<br>
Paul<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div><br></div>