[Distutils] add "sourceURL" to the metadata 3.0 PEP.

[Thomas Güttler]

Am 25.03.2017 um 06:38 schrieb Nick Coghlan:
> On 25 March 2017 at 07:12, Thomas Güttler <guettliml at thomas-guettler.de <mailto:guettliml at thomas-guettler.de>> wrote:
> 
>     Am 24.03.2017 um 05:59 schrieb Nick Coghlan:
>     > So the lesson we've learned is that for consumer tasks it's *always* better to start by asking "How can I best achieve my objective without asking publishers to change *anything*?".
>     >
>     > In the case of finding version control references, that's a matter of:
>     >
>     > - looking at Download-URL and Project-URL entries for links that "look like" version control references
>     > - if that doesn't turn up anything useful, scan the long description
>     > - once you have a repository reference, look for promising tag names (if the link didn't nominate a specific commit)
> 
>     This is the spirit of python packaging:
> 
>       We love guessing and trying we hate well defined datastructures.
> 
>     Yes, nothing is more boring then Entity–relationship models. But this provides solid ground.
> 
> 
> We've learned over the years that the data migration challenges involved in packaging metadata changes override essentially *every* other consideration. We've also learned that volunteers generally won't work on features they don't personally need, that commercial vendors will typically only fund work on their own downstream package management systems, and that if an opportunity arises to structurally bypass PyPA and python-dev as centralised approval authorities (aka procedural bottlenecks) we should take it.
> 
> Those lessons mean that all proposals for changes to the metadata now have to address two key not-so-simple questions:
> 
> 1. Is the idea still potentially useful even if *nobody except the person proposing it* ever adopts it?
> 2. Is a formal change to the interoperability specifications, with the associated delays in availability and adoption, the *only* way to solve the issue at hand?
> 


> This is a large part of why PEP 426 was deferred for so long, and why my recent changes to that PEP have all been directed at removing features rather than adding them.


This is great to hear! I tried to read it three times in the past. Everytime it took to long to read it. I was interrupted by more urgent stuff or I realized that I am tired
and need some hours of sleep.

This is my personal opinion: Why a PEP at all? I like this quote: rough consensus and running code.




> It's also why the accepted pyproject.toml proposal assumes that sdists will continue to include a setup.py shim for backwards compatibility with older tools that assume distutils/setuptools based build processes.

At university I was told to avoid redundancy. But you are the expert here. If you think redundancy is good here, then I think it is the right decision.

> 
> A "py-install-editable" utility that looks for an "Editable Source" label in Project-URL as a convention would meet those criterion, as it makes use of an existing v1.2 metadata field and shouldn't require any changes to pip, PyPI, setuptools, etc for people to enable it for their *own* projects - they'll just have to set Project-URL appropriately, and run "pip install py-install-editable && py-install-editable <project>". Whoever actually wrote the `py-install-editable` tool would have complete freedom to define the expected label name, as well as what fallback heuristics (if any) were tried in the event that the label wasn't set, without having to seek permission or approval from anyone else (not even distutils-sig).

OK, that sounds good. At first I had he impression that this is not possible. My idea could be implemented without modifying pip ... great.


> 
> If such a technique got popular enough, *then* we could look at elevating it beyond "Project URL with a conventional label backed up by an end user tool that reads that label" (e.g. by having "pip install -e" itself read the label, or enshrining the conventional label name in a PEP).

Yes, this sound good. This way the core does not get polluted by random crazy ideas.

Thank you very very much for listening.

Regards,
  Thomas Güttler


-- 
I am looking for feedback for my personal programming guidelines:
https://github.com/guettli/programming-guidelines