On Sep 21, 2018, at 8:14 AM, Paul Moore
wrote: On Fri, 21 Sep 2018 at 11:41, Nick Coghlan
mailto:ncoghlan@gmail.com> wrote: On Fri, 21 Sep 2018 at 05:47, Donald Stufft
wrote: On Sep 20, 2018, at 3:35 PM, Paul Moore
wrote: I don't think anyone's even spoken to the pip maintainers (yet?) about supporting the pipfile format That comes from me, I initially wrote the Pipfile as a proof of concept / sketch of an API for replacing the requirements.txt format, which Kenneth took and created pipenv from. At some point I plan on trying to push support for those ideas back into pip (not the virtual environment management bits though). That’s obviously my personal goal though, and doesn’t represent an agreed upon direction for pip.
And it's one where I think there are a couple of different levels of support that are worth considering:
Q. Should pip support installing from Pipfile.lock files as well as requirements.txt files?
A. Once the lock file format stabilises, absolutely, since this is squarely in pip's "component installer" wheelhouse.
Q. Should "pip install" support saving the installed components to a Pipfile, and then regenerating Pipfile.lock?
A. This is far less of a clearcut decision, as managing updates to a file that's intended to be checked in to source control is where I draw the line between "component installer" and "application/environment dependency manager".
Speaking as a pip developer:
Where's there a good summary of the pipfile format, the pipfile.lock format, and their relationship and contrast with requirements.txt? I don't view https://github.com/pypa/pipfile https://github.com/pypa/pipfile as a "good summary", because it explicitly states that pipfile is intended to *replace* requirements.txt, and I disagree strongly with that.
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” Digging back through my gists, I’m not sure I can find the original Pipfile idea, but I did find one of the early incantations of me sketching ideas out — https://gist.github.com/dstufft/e61c97ee30192e575140 https://gist.github.com/dstufft/e61c97ee30192e575140, I know I have others in my gists somewhere but I got tired of clicking through them.
Also, pipfile is human-readable, but pipfile.lock isn't. As far as I know, pipfile.lock is currently generated solely by pipfile - before pip consumes pipfile.lock, I'd like to see that format discussed and agreed as a formal interop standard that any tools wanting to pass data to pip (for the use case the standard describes) can use. One obvious thing I'd like to consider is changing the name to something less tool-specific - requirements.lock maybe?
So the name came from me, because at the time it was intended to be a pip specific format (though one of my TODOs was asking if the name made sense).
As far as the pipfile format is concerned, I see that more as pipenv's human readable input file that is used to *generate* the lock file, and I don't see it as something pip should consume directly, as that would mean pip overlapping in functionality with pipenv.
If I'm misunderstanding the relationship between pip and pipenv, or between pipenv and pipfile, I'm happy to be corrected. But can I suggest that the best way to do so would be to amend the project pages that are giving me the impressions I have above, and pointing me at the corrected versions? That way, we can make sure that any misinformation is corrected at source…
It’s probably not super productive to try to hash this stuff out now TBH, unless people are interested in it. It’s something I plan to explore, at some point, but I’m not doing so yet because I have higher priority things to work on, and AFAIK nobody else is planning on doing it currently (although maybe someone is?). There are some folks who know that I want to do it, who I maybe gave the wrong impression to that it was a done deal that it was going to happen, vs being something I wanted to do, but that may ultimately end up not happening.