On Fri, 21 Sep 2018 at 23:10, Donald Stufft <[email protected]> wrote: > So I should probably be explicit that this was basically an idea I had, that > Kenneth rolled with and originally tried to implement as a PR to pip but when > pip’s code base was too, gnarly to get it in directly, he made pipenv to wrap > pip to implement it, and since then pipenv has grown it’s own features and > such and is now an independent tool. Maybe it no longer makes sense for > Pipfile to be part of pip, maybe the idea is still good, but we need to do it > in a different way, I dunno. My thoughts aren’t really fully formulated on it > beyond “this is a thing I’d like to do, or at least explore doing” because > I’ve been focused on other things. > > The original intent *was* to replace requirements.txt, because the > requirements.txt format is not super great and is kind of unwieldy to work > with. It conflates the idea of a lock file with the idea of the things I > actually want to install, which makes it harder to work with than needs to > be. It’s fine-ish for simple stuff, since it ultimately ends up being a > simple text file, but the more complex you need to go, the worse it gets > since everything is implemented as a —flag=whatever option on the line, so > lines end up becoming huge and unwieldy. > > I don’t know that there’s a good summary available and honestly, I haven’t > tracked what has happened to the format since Kenneth started working on it, > so possible that my opinion is that the current state isn’t acceptable for > inclusion directly in pip! I wouldn’t know currently, the idea is very much > just a vague “I wanted this for pip years ago, pipenv actually implemented > it, it would be great to fold that back into pip”
https://github.com/pypa/pipfile/issues/108 is an issue I put together after starting to use pipenv and work with Kenneth, Dan, et al on pipenv UX design questions. TL;DR is that I think native Pipfile/Pipfile.lock support at the pip layer does still make sense, but the UX of it wouldn't look the same as it does in pipenv (since it would be an opt-in thing to request to track your changes to the current environment, rather than the default behaviour, and because pip *wouldn't* gain the ability to generate `Pipfile.lock` directly, only the ability to derive one from the current environment as part of `pip freeze`). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia -- 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/K3ZIR7PPY5OKMDBVLIRDBI4THUUTDJC4/
