<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 1, 2017, at 2:30 PM, Chris Barker <<a href="mailto:Chris.Barker@noaa.gov" class="">Chris.Barker@noaa.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class="">On Thu, Aug 31, 2017 at 9:23 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank" class="">ncoghlan@gmail.com</a>> wrote:<br class=""></div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">since it<br class="">
doesn't reliably distinguish between "this cached wheel was downloaded<br class="">
from a repository" and "this wheel was generated locally with a<br class="">
particular version of Python".</blockquote><div dir="auto" class=""><br class=""></div></div></div></div><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class="">It shouldn't have to. sigh.</div></div></div></div><div class=""><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> PEP 517 deliberately doesn't let<br class="">
frontends do that as part of the initial build process (instead, if<br class="">
they want to adjust the tags, they need to do it as a post-processing<br class="">
step).<br class="">
<br class="">
Since PEP 517 breaks the current workaround for the caching scheme<br class="">
being inaccurate, the most suitable response is to instead fix pip's<br class="">
caching scheme to use a two tier local cache:</blockquote><div dir="auto" class=""><br class=""></div></div></div></div><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class="">I'm still confused -- if setuptools ( invoked  by pip) is producing incorrectly named wheels -- surely that's a bug-fix/workaround that should go into setuptools?</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">If the build is being run by pip, then doesn't setuptools have all the info about the system that pip has?</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Someone building a wheel for distribution is likely intimately aware of that project, and can take care to ensure that the wheel is built in such a way that it is giving people the most optimal behavior. Pip is auto building wheels without human intervention, and as such there is nobody there to make sure that we’re not accidentally creating a too-broad wheel, so we want to ensure that we have some mechanism in place for not re-using the wheel across boundaries that might cause issues.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">we also have plenty of PyPI users that<br class="">
explicitly *opt out* of using publisher-provided pre-built binaries.<br class="">
While Linux distributions are the most common example (see [1] for<br class="">
Fedora's policy, for example), we're not the only ones that have that<br class="">
kind of rule in place.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">But this is an argument for why pypi should host sdists, and the build tools should build sdists, but not why pip should auto-build them.<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div dir="auto" class=""><br class=""></div></div></div></div><div class=""><div class="gmail_quote"><div dir="auto" class="">Condo-forge, for example, almost always builds from source -- sometimes an sdist </div><div dir="auto" class="">from pypi, sometimes a source distribution from github or wherever the package is hosted. And sometimes from a git tag ( last resort).</div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Pip supports more systems than Conda does, and we do that by relying on auto building support. Pip supports systems that don’t have a wheel compatibility tag defined for them, and for which we’re unlikely to ever have any wheels published for (much less wide spread). It’s pretty easy to cover Windows/macOS/Some Linux systems, but when you start talking about FreeBSD, OpenBSD, Solaris, AIX, HP-UX, etc then the long tail gets extremely long.</div><div><br class=""></div><div>Pip works in all these situations, and it does so by relying on building from source.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Do the Linux distros use pip to build their packages?</div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Not that I am aware of.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I tried to do that with conda-packages, and failed due to pip's caching  behavior-- it probably would have worked fine in production, but when I was developing the build script, I couldn't reliably get pip to ignore cached wheels from previous experimental builds.</div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Adding —no-cache-dir disables all of pip’s caching.</div></div><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">—<br class="">Donald Stufft<br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>