Re: Distlib vs Packaging (Was: disable building wheel for a package)

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/