Agreed. Furthermore, if people are of the opinion that pip's implementation is suitable, copying it out into packaging is likely not going to be at all controversial. Of course, it's not going to be any direct advantage to pip if that's done (we get the same functionality, just in a different place), so the people benefiting are those who want a supported API for that functionality, and it seems only reasonable to expect them to do the job of moving the code, rather than expecting the pip developers to do so.
In the case of pip's location code, more time has likely been spent discussing the problem than it would actually take to make the change. (Of course, no one person has spent that much time in discussions, but it adds up - coding doesn't work that way sadly). Paul On Tue, 18 Sep 2018 at 22:03, Donald Stufft <don...@stufft.io> wrote: > > > On Sep 18, 2018, at 4:31 PM, Dan Ryan <d...@danryan.co> wrote: > > As a consequence even though there are other libraries that may provide some > of this functionality, pip has the reference implementation and that > contains some significant additional logic. I don't imagine that pip is > going to simply adopt some new library without significant review... The > substantial effort required to actually get people to review the code > involved in standardizing the functionality people are 'borrowing' from pip > is probably going to be a challenge, and that's before we ever consider that > it will be difficult getting people to agree on what should be standardized > and extracted. > > > > Speaking for myself, generally if someone spins functionality out of pip into > a dedicated library, and that library is well tested, and has done the > diligence to ensure that answers aren’t changing if pip switches to that > library (or if they do change, they changed purposefully and we can document > it and deal with deprecation) then I don’t think there’s a whole lot of > blocker there. Obviously the level of review and testing should be > commiserate with the importance of the part that library controls. > > For instance when we switched to using packaging’s implementation of version > handling, I had spent hours compiling what the differences were going to be > between PEP 440 versions and the new version handling across all of PyPI. > However for platform detection for the User Agent we switched to a third > party library with just a cursory glance. > > Mainly I think the important thing, as far as pip is concerned, is for > someone to identify before hand what piece they want to carve out of pip into > a library and make sure that none of the pip developers have a problem with > that, then make sure that they do the diligence in making sure that the new > library matches the old behavior etc, and then submit a PR to pip that swaps > us to using it. For a lot of things, moving the reference implementation into > pypa/packaging is going to be the right answer, which is already bundled in > pip anyways. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/AQWSUKOUJVFH5N3L4HK3AIAWIA6ZAM7U/
