On Sep 19, 2018, at 11:54 PM, Dan Ryan <dan@danryan.co> wrote:

Since you mentioned following along, here's what we're working on right now:

https://github.com/sarugaku/requirementslib -- abstraction layer for parsing
and converting various requirements formats
(pipfile/requirements.txt/command line/InstallRequirement) and moving
between all of them
https://github.com/sarugaku/resolvelib -- directed acyclic graph library for
handling dependency resolution (not yet being used in pipenv)
https://github.com/sarugaku/passa -- dependency resolver/installer/pipfile
manager (bulk of the logic we have been talking about is in here right now)
-- I think we will probably split this back out into multiple other smaller
libraries or something based on the discussion
https://github.com/sarugaku/plette -- this is a rewrite of pipfile with some
additional logic / validation
https://github.com/sarugaku/shellingham -- this is a shell detection library
made up of some tooling we built in pipenv for environment detection
https://github.com/sarugaku/pythonfinder -- this is a library for finding
python (pep 514 compliant) by version and for finding any other executables
(cross platform)
https://github.com/sarugaku/virtenv -- python api for virtualenv creation

There’s been a lot of great discussion here, and I’m going to try to find time to go through these, though I wanted to make something explicit that I think maybe I was leaving implicit, and I thought should be made explicit:

Depending on how vital a particular bit of functionality is to pip, we’re likely going to want most libraries that are pulling functionality out of pip to live under the PyPA banner, and ideally should be setup in a way that existing pip contributors can work on them as well. While conceptually these are becoming distinct entities, for end users they’re going to be part of the nebulous thing that is pip, and changes and for “core” bits, pip wouldn’t want to lose the ability to work on these bits of functionality directly.

Obviously there is some stuff that isn’t “core” to what pip does, that we’re generally fine with being owned in a way that we aren’t part owners of. For instance we use requests, CacheControl, etc. The key difference there is that these are all things that aren’t really specific to pip’s core functionality (even though we may use them in implementing that) and so we don’t need to care too much about their implementation one way or another.

We’re also probably going to need/want to figure out some sort of shared requirements for things like “when do we drop support for a version of Python in xyzlib” and such like that.