On Fri, 21 Sep 2018 at 23:10, Donald Stufft <don...@stufft.io> 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   |   ncogh...@gmail.com   |   Brisbane, Australia
--
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/K3ZIR7PPY5OKMDBVLIRDBI4THUUTDJC4/

Reply via email to