<p dir="ltr"><br>
On Oct 3, 2015 12:36 PM, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
><br>
><br>
> On October 3, 2015 at 1:31:48 PM, Brett Cannon (<a href="mailto:brett@python.org">brett@python.org</a>) wrote:<br>
> > On Sat, 3 Oct 2015 at 04:51 Paul Moore wrote:<br>
> ><br>
> > > On 3 October 2015 at 02:03, Nathaniel Smith wrote:<br>
> > > > In particular I hesitate a little bit to just drop in everything from<br>
> > > > PEP 426 and friends, because previous specs haven't really thought<br>
> > > > through the distinction between sdists and wheels -- e.g. if an sdist<br>
> > > > generates two wheels, they probably won't have the same name,<br>
> > > > description, trove classifiers, etc. They may not even have the same<br>
> > > > version (e.g. if two different tools with existing numbering schemes<br>
> > > > get merged into a single distribution -- esp. if one of them needs an<br>
> > > > epoch marker). So it may well make sense to have an "sdist description<br>
> > > > field", but it's not immediately obvious that it's identical to a<br>
> > > > wheel's description field.<br>
> > ><br>
> > > I can only assume you're using the term sdist differently from the way<br>
> > > it is normally used (as in the PUG glossary), because for me the idea<br>
> > > that a sdist generates multiple wheels makes no sense.<br>
> > ><br>
> > > If I do "pip wheel " I expect to get a single wheel that<br>
> > > can be installed to give the same results as "pip install<br>
> > > " would, The wheel install will work on my build machine,<br>
> > > and on any machine where the wheel's compatibility metadata (the<br>
> > > compatibility tags, currently) says it's valid.<br>
> > ><br>
> > > The above behaviour is key to pip's mechanism for auto-generating and<br>
> > > caching wheels when doing an install, so I don't see how it could<br>
> > > easily be discarded.<br>
> > ><br>
> > > If what you're calling a "sdist" doesn't work like this, maybe you<br>
> > > should invent a new term, so that people don't get confused? If it<br>
> > > *does* work like this, I don't see what you mean by a sdist generating<br>
> > > two wheels.<br>
> > ><br>
> ><br>
> > I think sdist is getting a bit overloaded in this discussion. From my<br>
> > understanding of what Paul and Donald are after, the process should be:<br>
> ><br>
> > VCS -> sdist/source wheel -> binary wheel.<br>
> ><br>
> > Here, "VCS" is literally a git/hg clone of some source tree. A<br>
> > "sdist/source wheel" is carefully constructed zip file that contains all<br>
> > the source code from the VCS necessary to build a binary wheel for a<br>
> > project as long as the proper dependencies exist (e.g., proper version of<br>
> > NumPy, BLAS in one of its various forms, etc.). The binary wheel is<br>
> > obviously the final artifact that can just be flat-out loaded by Python<br>
> > without any work.<br>
> ><br>
> > So Paul doesn't see sdist/source wheels producing more than one binary<br>
> > wheel because in its own way an sdist/source wheel is a "compiled" artifact<br>
> > of select source code whose only purpose is to generate a binary wheel for<br>
> > a single project. So while a VCS clone might have multiple subprojects,<br>
> > each project should generate a single sdist/source wheel.<br>
> ><br>
> > Now this isn't to say that an sdist/source wheel won't generate different<br>
> > *versions* of a binary wheel based on whether e.g. BLAS is system-linked,<br>
> > statically linked, or dynamically loaded from a Linux binary wheel. But the<br>
> > key point is that the sdist/source wheel still **only** makes one kind of<br>
> > project.<br>
> ><br>
> > From this perspective I don't see Nathaniel's desire for installing from a<br>
> > VCS as something other than requiring a step to bundle up the source code<br>
> > into an sdist/source wheel that pip knows how to handle. But I think what<br>
> > Paul and Donald are saying is pip doesn't want to have anything to do with<br>
> > the VCS -> sdist/source wheel step and that is entirely up to the project<br>
> > to manage through whatever tooling they choose. I also view the<br>
> > sdist//source wheel as almost a mini-VCS checkout since it is just a<br>
> > controlled view of the source code with a bunch of helpful, static metadata<br>
> > for pip to use to execute whatever build steps are needed to get to a<br>
> > binary wheel.<br>
> ><br>
> > Or I'm totally wrong. =) But for me I actually like the idea of an<br>
> > sdist/source wheel being explained as "a blob of source in a structured way<br>
> > that can produce a binary wheel for the package" and a binary wheel as "a<br>
> > blob of bytes for a package that Python can import" and I'm totally fine<br>
> > having C extensions not just shuttle around a blind zip but a structured<br>
> > zip in the form of an sdist/source wheel.<br>
><br>
> This is basically accurate, the only thing is that I think that we do need an<br>
> answer for handling the VCS side of things, but I think that we should defer<br>
> it until after this PEP. Right now I think the PEP is trying to tackle two<br>
> different problems at once because on the surface they look similar but IMO<br>
> a VCS/arbitrary directory and a sdist are two entirely different things that<br>
> are only similar on the surface.<br>
><br>
> So Yes the path would be:<br>
><br>
> VCS -> sdist (aka Source Wheel or w/e) -> Wheel -> Install<br>
> \<br>
>  \-> "In Place" install (aka Development Install)<br>
><br>
> Right now, we have the Wheel -> Install part, and I'd like for this PEP to<br>
> focus on the sdist -> Wheel part, and then a future PEP focus on the VCS part.</p>
<p dir="ltr">thanks! is there a diagram of this somewhere?</p>
<p dir="ltr">Is this basically a FSM with URIs for each resource and transformation, where more specific attributes are added (e.g. to pydist.jsonld)? [PEP 426 JSONLD]</p>
<p dir="ltr">differences between VCS and sdist:<br>
* MANIFEST.in<br>
* setup.py<br>
* egg-info metadata</p>
<p dir="ltr">PEP 426 JSONLD: <a href="https://github.com/pypa/interoperability-peps/issues/31">https://github.com/pypa/interoperability-peps/issues/31</a></p>
<p dir="ltr">><br>
> -----------------<br>
> Donald Stufft<br>
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
><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">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>