<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>But the different builds for the different configurations end up with<br>
different metadata. If I'm understanding right, the whole point of<br>
"source wheels" is that they have all the static metadata that pip<br>
needs in order to make decisions, and this has to match the resulting<br>
wheels -- right?<br></blockquote><div><br></div><div>I think we're largely talking about variances in "external" non-python system dependencies (and their build settings).</div><div><br></div><div>PEP426 currently doesn't cover this in the core metadata, so as it stands, any 2.0 sdist couldn't exhaust these build variances in it's core metadata.</div><div><br></div><div>There has been some discussion on how to represent external dependencies.   In brief, I think the going idea is that it would be through extensions (<a href="https://www.python.org/dev/peps/pep-0426/#metadata-extensions">https://www.python.org/dev/peps/pep-0426/#metadata-extensions</a>), not in the core python metadata, and the various groups (distro folks, science folks, etc..) would implement these themselves to fulfill their needs...</div><div><br></div><div>Assuming they did implement such an extension, it would exist in the sdist, and for cases like numpy likely support some notion of "build options", and hence allow for a 1 to many mapping between sdist and binary wheels.</div><div><br></div><div>Marcus</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The way I'm imagining it is that there are multiple levels of metadata<br>
staticness:<br>
<br>
package name, author, description, ...<br>
  static in: VCS checkouts, source releases, source wheels, wheels<br>
package version<br>
  static in: source releases, source wheels, wheels<br>
package dependencies<br>
  static in: source wheels, wheels<br>
environment tag<br>
  static in: wheels<br>
<span class=""><br>
> Of course, there *is* an unsolved issue here, which is how we manage<br>
> compatibility for wheels at the level needed for numpy. But I thought<br>
> the discussion on that was ongoing? I'm concerned that this proposal<br>
> is actually about bypassing that discussion, and instead trying to<br>
> treat incompatibly linked wheels as "different" in terms of project<br>
> metadata, which I think is the wrong way of handling things. I note<br>
> that Christoph Gohlke's numpy builds are tagged with a "+mkl" local<br>
> version modifier - that's presumably intended to mark the fact that<br>
> they are built with an incompatible runtime - but that's a misuse of<br>
> local versions (and I've found it causes niggling issues with how pip<br>
> recognises upgrades, etc).<br>
<br>
</span>Yeah, that's not a good long term solution -- it needs to be moved<br>
into the metadata (probably by creating an MKL wheel and then making<br>
the numpy wheel depend on it). That's exactly the problem :-)<br>
<span class=""><br>
> So, in summary: Your points above don't seem to me to in any way<br>
> preclude having a single numpy source wheel, and a number of (mutually<br>
> incompatible, but the same in terms of project and version) binary<br>
> wheels.<br>
<br>
</span>Maybe I have misunderstood: does it actually help pip at all to have<br>
static access to name and version, but not to anything else? I've been<br>
assuming not, but I don't think anyone's pointed to any examples yet<br>
of the problems that pip is encountering due to the lack of static<br>
metadata -- would this actually be enough to solve them?<br>
<span class="im"><br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="http://vorpus.org" rel="noreferrer" target="_blank">http://vorpus.org</a><br>
</span><div class=""><div class="h5">_______________________________________________<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" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>