<div>On Sat, Sep 2, 2017 at 5:17 PM xoviat <<a href="mailto:xoviat@gmail.com">xoviat@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Whatever it was, removing it seems to have had no effect on the tests. I will remove it unless someone has an objection.</div></blockquote><div dir="auto"><br></div><div dir="auto">Just FYI, I wouldn't take the tests still passing as a major signal. I've noticed there are even common code paths / functional scenarios that aren't under test.</div><div dir="auto"><br></div><div dir="auto">--Chris</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-09-02 18:26 GMT-05:00 xoviat <span><<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Donald, <div><br></div><div><br></div><div>This was your work in <a href="https://github.com/pypa/pip/pull/2169" target="_blank">https://github.com/pypa/pip/pull/2169</a>. Unfortunately the comments were quite sparse.</div></div><div class="m_1087196717841082763HOEnZb"><div class="m_1087196717841082763h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-09-02 18:25 GMT-05:00 xoviat <span><<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>One more issue that has come up is that "--no-user-cfg" seems to be passed to the egg_info invocation if the "isolated" parameter is enabled. I don't understand what this does, but it is again not defined in the PEP 517 interface. Should we always pass this parameter or should we never pass it?</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_1087196717841082763m_2775775697871390886h5">2017-09-02 14:42 GMT-05:00 Donald Stufft <span><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_1087196717841082763m_2775775697871390886h5"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Sep 1, 2017, at 2:30 PM, Chris Barker <<a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>> wrote:</div><br class="m_1087196717841082763m_2775775697871390886m_4619906384466988869m_1323752169446061147Apple-interchange-newline"><div><div><div><div class="gmail_quote"><div dir="auto">On Thu, Aug 31, 2017 at 9:23 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">since it<br>
doesn't reliably distinguish between "this cached wheel was downloaded<br>
from a repository" and "this wheel was generated locally with a<br>
particular version of Python".</blockquote><div dir="auto"><br></div></div></div></div><div><div><div class="gmail_quote"><div dir="auto">It shouldn't have to. sigh.</div></div></div></div><div><div><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"><br></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>
frontends do that as part of the initial build process (instead, if<br>
they want to adjust the tags, they need to do it as a post-processing<br>
step).<br>
<br>
Since PEP 517 breaks the current workaround for the caching scheme<br>
being inaccurate, the most suitable response is to instead fix pip's<br>
caching scheme to use a two tier local cache:</blockquote><div dir="auto"><br></div></div></div></div><div><div><div class="gmail_quote"><div dir="auto">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"><br></div><div dir="auto">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"><br></div><div dir="auto"><br></div></div></div></div></div></blockquote><div><br></div><div><br></div></span><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><span><div><br></div><br><blockquote type="cite"><div><div><div><div class="gmail_quote"><div dir="auto"><br></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>
explicitly *opt out* of using publisher-provided pre-built binaries.<br>
While Linux distributions are the most common example (see [1] for<br>
Fedora's policy, for example), we're not the only ones that have that<br>
kind of rule in place.</blockquote><div dir="auto"><br></div><div dir="auto">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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div dir="auto"><br></div></div></div></div><div><div class="gmail_quote"><div dir="auto">Condo-forge, for example, almost always builds from source -- sometimes an sdist </div><div dir="auto">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></div><div><br></div></span><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></div><div>Pip works in all these situations, and it does so by relying on building from source.</div><span><div><br></div><br><blockquote type="cite"><div><div><div class="gmail_quote"><div dir="auto"><br></div><div dir="auto">Do the Linux distros use pip to build their packages?</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>Not that I am aware of.</div><span><br><blockquote type="cite"><div><div><div class="gmail_quote"><div dir="auto"><br></div><div dir="auto">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></div><div><br></div></span><div>Adding —no-cache-dir disables all of pip’s caching.</div></div><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-ligatures: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;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br>—<span class="m_1087196717841082763m_2775775697871390886m_4619906384466988869HOEnZb"><font color="#888888"><br>Donald Stufft<br></font></span></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-ligatures: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;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br></div><br class="m_1087196717841082763m_2775775697871390886m_4619906384466988869m_1323752169446061147Apple-interchange-newline">
</div>
<br></div><br></div></div><span>_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div></div>