Thanks for the advices, they are really helpful. Incidentally (or maybe not? I wonder if there is an underlying pattern here) the two areas I do want to work on first are a) how to find a package, and b) how to choose an artifact for a given package.
I think I’m starting with the package discovery part first and work my way from there. I’ll create an issue in pypa/pip and try to outline the intention (and summarise this thread), but there’s a couple of things I wish to clarify first: 1. Should dependency link processing be included? Since it is un-deprecated now, I guess the answer is yes? 2. (Maybe not an immediate issue) What formats should I include? Wheels and .tar.gz sdists, of course, what others? Eggs? .zip sdists? Are there other formats? TP > On 20/9, 2018, at 02:40, Paul Moore <p.f.mo...@gmail.com> wrote: > > On Wed, 19 Sep 2018 at 18:52, Donald Stufft <don...@stufft.io> wrote: >> >> On Sep 19, 2018, at 1:14 PM, Tzu-ping Chung <uranu...@gmail.com> wrote: >> >> I feel the plan is quite solid. This however leaves us (who want a Python >> implementation and interface to do what pip does) in an interesting place. >> So I can tell there are a couple of principles: >> >> 1. Do not use pip internals >> 2. pip won’t be using either distlib or setuptools, so they might not match >> what pip does, in the long run >> >> Does this leaves us only one option left, to implement a library that >> matches what pip does (follows the standards), but is not pip? That feels >> quite counter-productive to me, but if it’s what things would be, I’d accept >> it. >> >> The next step (for me) in that case would then be to start working on that >> library. Since existing behaviours in setuptools and pip (including the part >> it uses distlib for) are likely to be standardised, I can rely on distlib >> for script creation, setuptools for some miscellaneous things (editable >> installs?), and pull (or reimplement) parts out of pip for others. Are there >> caveats I should look out? >> >> >> My general recommendation if you want a Python implementation/interface for >> something pip does, is: >> >> - Open an issue on the pip repository to document your intent and to make >> sure that there is nobody there who is against having that functionality >> split out. This might also give a chance for people with familiarity in that >> API to mention pain points that you can solve in a new API. We can also >> probably give you a good sense if the thing you want in a library is >> something that probably has multiple things that are dependent on getting >> split out first (for instance, if you said you wanted a library for >> installing wheels, we’d probably tell you that there is a dependency on PEP >> 425 tags, pip locations, maybe other that need resolved first) and also >> whether this is something that should have a PEP first or not. Getting some >> rough agreement on the plan to split X thing out before you start is overall >> a good thing. >> >> - Create or update a PEP if required, and get it into the provisional state. >> >> - Make the library, either as a PR to packaging or as it’s own independent >> library. If there are questions that come up while creating that library/PR >> that have to do with specific pip behaviors, go back to that original issue >> and ask for clarification etc. Ideally at some point you’ll open a PR on pip >> that uses the new library (my suggestion is to not bundle the library in the >> initial PR, and just import it normally so that the PR diff doesn’t include >> the full bundled library until there’s agreement on it). If there’s another >> tool (pipenv, whatever) that is looking to use that same functionality, open >> a WIP PR there too that switches it to using that. Use feedback and what you >> learn from trying to integrate in those libraries to influence back the >> design of the API itself. >> >> Creating a PEP and creating the library and the PRs can happen in parallel, >> but at least for pip if something deserves a PEP, we’re not going to merge a >> PR until that PEP is generally agreed on. However it can be supremely useful >> to have them all going at the same time, because you run into things that >> you didn’t really notice until you went to actually implement it. >> >> My other big suggestion would be to e careful about how much you bite off at >> one time. Pip’s internal code base is not the greatest, so pulling out >> smaller chunks at a time rather than trying to start right off pulling out a >> big topic is more likely to meet with success. Be cognizant of what the >> dependencies are for the feature you want to implement, because if it has >> dependencies, you’ll need to pull them out first before you can pull it out >> OR you’ll need to design the API to invert those dependencies so they get >> passed in instead. >> >> I personally would be happy to at a minimum participate on any issue where >> someone was trying to split out some functionality from pip into a re-usable >> library if not follow the develop of that library directly to help guide it >> more closely. My hope for pip is that it ends up being the glue around a >> bunch of these libraries, and that it doesn’t implement most of the stuff >> itself anymore. > > I basically agree with everything Donald said, and I'd also be happy > to support any work along these lines. If you're looking for a place > to start, I'd strongly recommend some of the foundational areas - > something like pip.locations (I know there are others who have > expressed an interest in this PI being exposed), or pep425tags which > has the advantage of already having a standard, or something at that > level. Starting with something at the level of the finder or the > installer is likely to be way too much to start with, even if it feels > like it would be more directly useful to you. > > 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/J4FHFMHLIKNPMOWLFTEIGRR4H5XGWPRD/
