> On Sep 19, 2018, at 11:54 PM, Dan Ryan <d...@danryan.co> wrote:
>
> Since you mentioned following along, here's what we're working on right now:
>
> https://github.com/sarugaku/requirementslib
> <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
> <https://github.com/sarugaku/resolvelib> -- directed acyclic graph library for
> handling dependency resolution (not yet being used in pipenv)
> https://github.com/sarugaku/passa <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 <https://github.com/sarugaku/plette> --
> this is a rewrite of pipfile with some
> additional logic / validation
> https://github.com/sarugaku/shellingham
> <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
> <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 <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.
--
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/YYRENORJIQHLDQ3PK64FLXTDDJXSAIP4/
