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

[Donald Stufft]

On October 5, 2015 at 10:52:22 AM, Antoine Pitrou (solipsis at pitrou.net) wrote:
> On Mon, 5 Oct 2015 09:51:05 -0400
> Donald Stufft wrote:
> >
> > You can see these needs are different I think by looking at how what Nathaniel wants differs  
> from what me and Paul want. He wants something that will make the human side easier and  
> will support different tools, we want something that pip can consume more reasonably.  
> Trying to do too much with a singular format just means it sucks for all the uses cases instead  
> of being great for one use case.
>  
> That doesn't seem to follow. You can have regular human-compatible
> content and a few machine-compatible files besides (perhaps in a
> dedicated subdirectory). I don't see how that "sucks”.

Machine compatible needs things to be as tightly specified as possible, human
compatible needs it to be as loosely specified as possible. In addition, the
original proposal had things like "version" being dynamically computed because
it might change based on something in the directory (like if the VCS gets
another commit). For a machine format, we want all metadata to be static, for
something designed for humans to interact with and much around with the code
we want something that is more dynamic.

If you have two different files one for machines and one for humans, what
happens if they disagree? There should be a single source of truth in any one
artifact for all of the information. We currently have the situation you
describe, a PKG-INFO that is static metadata and a setup.py that is aimed
towards humans... but nothing uses the PKG-INFO because the source of truth is
the setup.py and the PKG-INFO might be lies. So we have a lot of effort and
hacks going in to make something that is best designed for human interaction
to be used for machines.

>  
> > I also don't think it will be confusing. They'll associate the VCS thing (a source release)  
> as something focused on development for most everyone. Most people won't explicitly  
> make one and nobody will be uploading it to PyPI.
>  
> Well, what is the point of standardizing the concept of source releases
> if nobody produces them?
>  

Well, a VCS commit will be a form of one, just not one that people explicitly
distribute. I don't think it makes a sense to standard this idea of a
"source release" as something different other than what we need to bootstrap
a VCS based build as well. So we need to support it for VCSs anyways, and
divorcing the standard from VCSs makes it more robust and allows the idea of
a .tar.gz based "VCS" build anyways.

I also didn't say nobody would produce them. I said most people would have no
need for explicit source releases (particularly in a tarball form) and wouldn't
produce them. If I thought *nobody* would produce them, then I wouldn't be
willing to have them standardized. I think that they might be useful for some
projects that have more advanced needs.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA