<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On 23 August 2017 at 01:37, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...]<br>
<br>
Bootstrapping self-hosted packaging tools is a genuinely hard problem<br></blockquote><div><br></div><div>True, but on the other hand, it's the self-hosted packaging tools' own problem. It's up to the tools themselves to solve it.</div><div><br></div><div>if PEP 517 simply establishes that the current directory of the source distribution will be naturally at the head of `sys.path` (whether an original checkout or a cleaned up sdist), then self-hosted packaging tools can be their own backend, and do whatever magick they need to self-bootstrap.</div><div><br></div><div>It makes sense to think a bit about whether we're not making these cases harder, but we shouldn't block progress of PEP 517 on account of these cases.</div><div><br></div><div>If we specifically want to make these cases easier in the future, we might think of another PEP to expose to backends certain frontend operations like "provide me the sdist (or wheel) for requirement foo >= 2.3.0 but don't install it and don't fetch dependencies" so we can make sure certain configurations like "what is the index server?" or "how do I use a web proxy?" are centralized and consistent.<br></div><div><br></div><div>Regards,</div><div><br></div><div>Leo<br></div></div></div></div></div>