Re: disable building wheel for a package

> On 19/9, 2018, at 16:02, Paul Moore <[email protected]> wrote:
> 
> On Wed, 19 Sep 2018 at 00:52, Dan Ryan <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/XJC3BXEX5N4PCLNQ3XKKCGOIMCMP3LH4/
--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/25T4YPMHJ2Z4T5MDDVCP2LM3K4VEOZOD/