On Wed, 19 Sep 2018 at 11:41 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. >
And if you start with pep425tags I have a bunch of notes for you. ;) (CoC stuff has sucked almost all of my volunteer time for the past two weeks so I have not had a chance to try to write up a proposed library for PEP 425 like I had planned to.) -Brett > > 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/24MLWSVM3SW5QUNPNSXAOXI3N4UOLXBX/ >
-- 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/CDGEHCTSGVE7IRKBD7NJEFKML5OZ7ORC/
