On 25 March 2017 at 07:12, Thomas Güttler <guettl...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig