> On 19/9, 2018, at 16:02, Paul Moore <p.f.mo...@gmail.com> wrote: > > On Wed, 19 Sep 2018 at 00:52, Dan Ryan <d...@danryan.co> wrote: >> >>> 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. >> >> This is where I think we disagree and I feel the rhetoric is a bit harmful >> -- personally I don't benefit much at all, I actually don't think any >> individual maintainer inside the PyPA benefits much beyond having a new >> project to maintain, so the 'helps me vs helps you' framing isn't really the >> point. If it strictly helped me to add a project to my list of things to >> maintain I would have done that already. The real issue here is that we all >> have different implementations and they create non-uniform / disjointed user >> experiences. Converging on a set of common elements to extract seems like >> step 1 >> >> I am fairly new to the PyPA, and I don't know how any of these processes >> actually work. But I do know that painting this as "us vs you" when my >> interest actually in helping the user of packaging tools is causing a >> disconnect for me anytime we engage on this -- and I'm not asking you to >> tackle any of this yourself, except possibly review someone's PR down the >> road to swap out some internals. > > Apologies. I misread your email, and so I was mostly addressing the > issues we've seen posted to pip asking for us to simply expose the > internal functions, not your comment about multiple projects > implementing the logic. Sorry for that. Agreed if we already have > multiple implementations, merging them is a useful thing, but the > benefits are diffuse and long term, so it's the sort of thing that > tends to remain on the back burner indefinitely. (One of the problems > with open source is that unless something is *already* available as a > library, we tend to reimplement rather than refactoring existing code > out of a different project, because the cost of that interaction is > high - which unfortunately I demonstrated above by my comment "people > needing an API should do the work" :-().
Risking thread hijacking, I want to take this chance and ask about one particular multiple implementation problem I found recently. What is the current situation regarding distlib vs packaging and various pieces in pip? Many parts of distlib seems to have duplicates in either packaging or pip/setuptools internals. I understand this is a historical artifact, but what is the plan going forward, and what strategy, if any, should a person take if they are to make the attempt of merging, or collecting pieces from existing code bases into a workable library? From what I can tell (very limited), distlib seems to contain a good baseline design of a library fulfilling the intended purpose, but is currently missing parts to be fully usable on its own. Would it be a good idea to extend it with picked parts from pip? Should I contribute directly to it, or make a (higher level) wrapper around it with those parts? Should I actually use parts from it, or from other projects (e.g. distlib.version vs packaging.version, distlib.locator or pip’s PackageFinder)? It would be extremely helpful if there is a somewhat general, high-level view to the whole situation. TP > > Paul > -- > 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/XJC3BXEX5N4PCLNQ3XKKCGOIMCMP3LH4/ -- 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/25T4YPMHJ2Z4T5MDDVCP2LM3K4VEOZOD/
