On Fri, 21 Sep 2018 at 11:41, Nick Coghlan <ncogh...@gmail.com> wrote: > > On Fri, 21 Sep 2018 at 05:47, Donald Stufft <don...@stufft.io> wrote: > > On Sep 20, 2018, at 3:35 PM, Paul Moore <p.f.mo...@gmail.com> 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 as a "good summary", because it explicitly states that pipfile is intended to *replace* requirements.txt, and I disagree strongly with that. 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? 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... Paul PS Full disclosure - I've tried to use pipenv in a couple of local projects, because of the hype about it being the "great new thing" and found it basically of no use for my requirements/workflow. So I may have a biased view of either pipenv, or how it's being presented. I'm trying to be objective in the above, but my bias may have slipped through. -- 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/SR3FAMLZM646GT3IPYFILD47KMRWOALD/
