Am 25.03.2017 um 06:38 schrieb Nick Coghlan: > On 25 March 2017 at 07:12, Thomas Güttler <guettl...@thomas-guettler.de > <mailto: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. 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
