[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Donald Stufft]

On October 8, 2015 at 8:48:16 AM, Oscar Benjamin (oscar.j.benjamin at 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