<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 2 Oct 2015 at 05:08 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On October 2, 2015 at 12:54:03 AM, Nathaniel Smith (<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>) wrote:<br>
> > We realized that actually as far as we could tell, it wouldn't<br>
> be that<br>
> hard at this point to clean up how sdists work so that it would be<br>
> possible to migrate away from distutils. So we wrote up a little<br>
> draft<br>
> proposal.<br>
><br>
> The main question is, does this approach seem sound?<br>
<br>
I've just read over your proposal, but I've also just woken up so I might be<br>
a little slow still! After reading what you have, I don't think that this<br>
proposal is the right way to go about improving sdists.<br>
<br>
The first thing that immediately stood out to me, is that it's recommending<br>
that downstream redistributors like Debian, Fedora, etc utilize Wheels instead<br>
of the sdist to build their packages from. However, that is not really going to<br>
fly with most (all?) of the downstream redistributors. Debian for instance has<br>
policy that requires the use of building all of it's packages from Source, not<br>
from anything else and Wheels are not a source package. While it can<br>
theoretically work for pure python packages, it quickly devolves into a mess<br>
when you factor in packages that have any C code what so ever.<br></blockquote><div><br></div><div>So wouldn't they then download the sdist, build a wheel as an intermediate, and then generate the .deb file? I mean as long as people upload an sdist for those that want to build from source and a wheel for convenience -- which is probably what most people providing wheels do anyway -- then I don't see the problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Overall, this feels more like a sidegrade than an upgrade. One major theme<br>
throughout of the PEP is that we're going to push to rely heavily on wheels as<br>
the primary format of installation. While that works well for things like<br>
Debian, I don't think it's going to work as wheel for us. If we were only<br>
distributing pure python packages, then yes absolutely, however given that we<br>
are not, we have to worry about ABI issues. Given that there is so many<br>
different environments that a particular package might be installed into, all<br>
with different ABIs we have to assume that installing from source is still<br>
going to be a primary path for end users to install and that we are never going<br>
to have a world where we can assume a Wheel in a repository.<br>
<br>
One of the problems with the current system, is that we have no mechanism by<br>
which to determine dependencies of a source distribution without downloading<br>
the file and executing some potentially untrusted code. This makes dependency<br>
resolution harder and much much slower than if we could read that information<br>
statically from a source distribution. This PEP doesn't offer anything in the<br>
way of solving this problem.<br></blockquote><div><br></div><div>Isn't that what the requirements and requirements-file fields in the _pypackage file provide? Only if you use that requirements-dynamic would it require execcuting arbitrary code to gather dependency information, or am I missing something?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To a similar tune, this PEP also doesn't make it possible to really get at<br>
any other metadata without executing software. This makes it pratically<br>
impossible to safely inspect an unknown or untrusted package to determine what<br>
it is and to get information about it. Right now PyPI relies on the uploading<br>
tool to send that information alongside of the file it is uploading, but<br>
honestly what it should be doing is extracting that information from within the<br>
file. This is sort of possible right now since distutils and setuptools both<br>
create a static metadata file within the source distribution, but we don't rely<br>
on that within PyPI because that information may or may not be accurate and may<br>
or may not exist. However the twine uploading tool *does* rely on that, and<br>
this PEP would break the ability for twine to upload a package without<br>
executing arbitrary code.<br></blockquote><div><br></div><div>Isn't that only if you use the dynamic fields?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Overall, I don't think that this really solves most of the foundational<br>
problems with the current format. Largely it feels that what it achieves is<br>
shuffling around some logic (you need to create a hook that you reference from<br>
within a .cfg file instead of creating a setuptools extension or so) but<br>
without fixing most of the problems. The largest benefit I see to switching to<br>
this right now is that it would enable us to have build time dependencies that<br>
were controlled by pip rather than installed implicitly via the execution of<br>
the setup.py. That doesn't feel like a big enough benefit to me to do a mass<br>
shakeup of what we recommend and tell people to do. Having people adjust and<br>
change and do something new requires effort, and we need something to justify<br>
that effort to other people and I don't think that this PEP has something we<br>
can really use to justify that effort.<br></blockquote><div><br></div><div>>From my naive perspective this proposal seems to help push forward a decoupling of building using distutils/setuptools as the only way you can properly build Python projects (which is what I think we are all after) and will hopefully eventually free pip up to simply do orchestration.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I *do* think that there is a core of some ideas here that are valuable, and in<br>
fact are similar to some ideas I've had. The main flaw I see here is that it<br>
doesn't really fix sdists, it takes a solution that would work for VCS<br>
checkouts and then reuses it for sdists. In my mind, the supported flow for<br>
package installation would be:<br>
<br>
    VCS/Bare Directory -> Source Distribution -> Wheel<br>
<br>
This would (eventually) be the only path that was supported for installation<br>
but you could "enter" the path at any stage. For example, if there is a Wheel<br>
already available, then you jump right on at the end and just install that, if<br>
there is a sdist available then pip first builds it into a wheel and then<br>
installs that, etc.<br>
<br>
I think your PEP is something like what the VCS/Bare Directory to sdist tooling<br>
could look like, but I don't think it's what the sdist to wheel path should<br>
look like. <br></blockquote><div><br></div><div>Is there another proposal I'm unaware for the sdist -> wheel step that is build tool-agnostic? I'm all for going with the best solution but there has to be an actual alternative to compare against and I don't know of any others right now and this proposal does seem to move things forward in a reasonable fashion.</div></div></div>