On October 8, 2015 at 8:48:16 AM, Oscar Benjamin (oscar.j.benja...@gmail.com) wrote: > On 8 October 2015 at 13:05, Ionel Cristian Mărieș wrote: > > On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin > > wrote: > >> > >> I think this satisfies all of the requirements for static metadata and > >> one-to-one correspondence of source wheels and binary wheels. If numpy > >> followed this then I imagine that there would be a single source wheel > >> on PyPI corresponding to the one configuration that would be used > >> consistently there. However numpy still needs to separately release > >> the code in a form that is also usable in all of the many other > >> contexts that it is already used. > > > > Can't that configuration just be the build defaults? There would be a single > > source but with some preset build configuration. People with different needs > > can just override those. > > Yeah, I guess so. Maybe I'm just not understanding what the > "one-to-one" correspondence is supposed to mean. Earlier in the thread > it was said to be important because of wheel caching etc. but if it's > possible to configure different builds then it's not really > one-to-one. >
One of the features in the original PEP was the ability to produce multiple different Wheels from the same source release much like how Debian does. e.g. numpy-1.0.newsdistthing could produce numpy-pyopenblas-12.6.whl and numpy-mkl-7.8.whl, etc etc where there would be a bunch of names/versions that would differ from the name/version of the original sdist thing that was being proposed. That won't work with our packaging toolchain, the idea that their a singular name/version for one sdist (and then for the wheels that produces) is pretty heavily baked into the entire toolchain. That’s what I meant by wheels and sdists being 1:1. As far as static metadata goes, I think that one of my earlier messages tried to get across the idea that if there is a good reason for something to be dynamic then we can possibly do that, but that the current PEP went too far and made (well kept) *everything* dynamic. My point was that we should assume static for all metadata and then make exceptions for the data that we can't assume that for, but each case should be properly documented with motivations or *why* that can't be static. That will give everyone else the ability to see the use case, and figure out if that’s a use case we want to support, if we like how the PEP is supporting it, or if there is possibly some other feature we could add instead that would still support that, while offering the static-ness that we desire. Or if not, at least we'll have it documented as to *why* it needs to be dynamic. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
