<p dir="ltr">On May 13, 2016 11:34 AM, "Chris Barker" <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
><br>
> One other question:<br>
><br>
> Is it just examples or is "build" being defined as "build a wheel"?<br>
><br>
> i.e. there are times one might want to build a package without building a wheel -- just it install it yourself, or to put it in another package format -- conda, rpm, what have you.<br>
><br>
> In conda's case, building a wheel, and then installing it would work fine, but I'm not sure we want to lock that down as the only way to build a package.</p>
<p dir="ltr">As Brett already clarified, this pep is just about how you get to the point of being able to start the build system; it doesn't care what the build system actually outputs.</p>
<p dir="ltr">But, the plan *is* to make wheels the standard way to build packages -- that will be in the next pep :-). I'm not sure I'd call it "lock down", because there's nothing that will stop you running setup.py bdist_rpm or whatever. But our goal is to reach the point where package authors get a choice of what build system to use, and there's no guarantee that every build system will implement bdist_rpm.</p>
<p dir="ltr">So, the plan is to require all build systems to be able to output wheels, and then debian or conda-build or whoever will convert the wheel into whatever final package format they want. This is way more scalable than requiring N different build systems to each be able to output M different formats for N*M code paths. And if wheels aren't sufficient, well, we can add stuff to the spec :-)</p>
<p dir="ltr">-n</p>