On Wed, 19 Sep 2018 at 00:52, Dan Ryan
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" :-(). Paul