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

[Nick Coghlan]

On 25 March 2017 at 07:12, Thomas Güttler <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. 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.

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).

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).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170325/1c649193/attachment.html>