New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git - Should Pipfile.lock be committed to version control? #598

Closed
LeCoupa opened this Issue Sep 19, 2017 · 15 comments

Comments

Projects
None yet
10 participants
@LeCoupa

LeCoupa commented Sep 19, 2017

When two developers are working on a projet with different operating systems, the Pipfile.lock is different (especially the part inside host-environment-markers).

For Composer, most people recommend to commit composer.lock. Do we have to do the same for Pipenv?

@kennethreitz

This comment has been minimized.

Contributor

kennethreitz commented Sep 19, 2017

i recommend it.

@kennethreitz

This comment has been minimized.

Contributor

kennethreitz commented Sep 19, 2017

Especially for applications. For libraries, less so.

@LeCoupa

This comment has been minimized.

LeCoupa commented Sep 19, 2017

Thanks a lot @kennethreitz

@salty-horse

This comment has been minimized.

salty-horse commented Oct 1, 2017

Should this recommendation be documented? Perhaps in a section similar to Composer's.

@dougireton

This comment has been minimized.

dougireton commented Jan 30, 2018

Are their negative consequences to using a Pipfile.lock across OS types? In other words, if I generate my Pipfile.lock on MacOS, then deploy to Linux will Pipenv "do bad things"?

@uranusjr

This comment has been minimized.

Member

uranusjr commented Jan 31, 2018

@dougireton This depends on your dependencies. Using a lockfile from a different OS is fine if all your packages are modern and well-behaved (either platform-agnostic or have good cross-platform support). Otherwise Pipenv can do things wrong, like installing dependencies that don’t work, or not installing all needed dependencies.

@kennethreitz

This comment has been minimized.

Contributor

kennethreitz commented Feb 17, 2018

Generally, yes you should commit it to version control.

@behrangsa

This comment has been minimized.

behrangsa commented Feb 28, 2018

How come pipenv's own Pipefile.lock is not added to git then?

@kennethreitz

This comment has been minimized.

Contributor

kennethreitz commented Feb 28, 2018

because we are special snowflakes.

@anentropic

This comment has been minimized.

anentropic commented Mar 7, 2018

I'm happy to take this advice as correct but I would like to understand why it is given.

the docs say:

Generally, keep both Pipfile and Pipfile.lock in version control.

but I couldn't find any more reasoning in the docs, can you point me to it?

Pipfile.lock is auto-generated and contents will differ depending on platform. If I'm developing on macOS and deploying to Debian ...already it sounds to me like I don't want the lock file in version control.

Then the comment above says:

Using a lockfile from a different OS is fine if all your packages are modern and well-behaved (either platform-agnostic or have good cross-platform support). Otherwise Pipenv can do things wrong, like installing dependencies that don’t work, or not installing all needed dependencies.

Again it sounds like I would not want the lock file in version control.

Here is someone asking similar question #954

Reading through the responses on that issue I have a clearer idea of why I would want it. I think the docs need more elaboration.

The related question is how explicitly should versions be specified in the Pipfile?

If I do pipenv install <package> during development to get the latest version, it will go in the Pipfile with no version specifier. If everyone else gets my Pipfile.lock from vc and does pipenv install --ignore-pipfile they get pinned to the versions I installed, and no need to be more specific in the Pipfile. All good. If they don't do --ignore-pipfile then the lock file may change if a package updated and they have to decide whether to commit the changes. Ok. At any time devs can pipenv update <package> and the Pipfile won't change but the lock file will, and we would commit that. Ok. Is this the intended workflow?

But if the other dev is on a different platform the lock file contents will change(?) but it's not necessarily due to different package versions and we wouldn't want to commit it. Hmm.

And I would only add version specifier to Pipfile if for example I knew at dev time that I needed to install a non-latest version?

Also I noticed in the example Dockerfile you use pipenv install --deploy rather than pipenv install --ignore-pipfile ...they seem to have similar meaning, I would like to understand the subtlety of one vs the other.

(loving pipenv so far though!)

@anentropic

This comment has been minimized.

anentropic commented Mar 13, 2018

I just found some more opinion from the pipenv tool itself:

requirements.txt found, instead of Pipfile! Converting…
Warning: Your Pipfile now contains pinned versions, if your requirements.txt did.
We recommend updating your Pipfile to specify the "*" version, instead.
@uranusjr

This comment has been minimized.

Member

uranusjr commented Mar 14, 2018

This thread is quite old, but since it emerges again I guess it is best to make a definite, up-to-date statement. As of March 2018, the answer to this question is yes, you should always commit the lock file. Always.

@mmohaveri

This comment has been minimized.

mmohaveri commented Apr 1, 2018

@uranusjr could you please explain why?

what has changed in March 2018 that changed the answer from "generally yes" to "always yes"?

What about the issue you explain earlier, is it fixed?

Using a lockfile from a different OS is fine if all your packages are modern and well-behaved (either platform-agnostic or have good cross-platform support). Otherwise Pipenv can do things wrong, like installing dependencies that don’t work, or not installing all needed dependencies.

@techalchemy

This comment has been minimized.

Member

techalchemy commented Apr 1, 2018

Nothing is different. You should commit it to version control. If there are os-specific markers they should be included automatically. Because setup.py files are non-deterministic, it is possible to resolve a package on linux and find that it resolves differently on windows, but there is nothing we or anyone else besides the package maintainer can do about that. You won't know that's a problem unless you encounter it. If and when you do, simply re-lock and see the diff.

@gsemet

This comment has been minimized.

Contributor

gsemet commented Apr 1, 2018

For application using pipenv, yes you track the lock files.

My librairies however I write using pipenv (and use PBR to reflect to setup.py and an automatic generation of requirements.txt so PBR is happy once the package is deployed), I do not track the lock file. Pretty simple

Hanse00 added a commit to Hanse00/LecToCal that referenced this issue May 26, 2018

Additional research (See pypa/pipenv#598 and https://stackoverflow.co…
…m/questions/46330327/please-explain-the-usage-of-pipfile-and-pipfile-lock) suggests the Pipenv should be versioned as well.

This is to help others build the tool easily. I've decided to start tracking the Pipenv as such, however as of this commit, the pipenv contains far from all dependencies. I will be slowly working those into the pipenv.

@lithp lithp referenced this issue Jun 28, 2018

Merged

Mitmproxy-based automated failure testing #2119

6 of 16 tasks complete

dmd pushed a commit to dmd/qrplay that referenced this issue Sep 13, 2018

@zeroSteiner zeroSteiner referenced this issue Oct 9, 2018

Merged

pipenv enviroment #325

3 of 3 tasks complete

sdrogers added a commit to sdrogers/nplinker that referenced this issue Oct 29, 2018

added pipfile.lock (as recommended here pypa/pipenv#598) and removed …
…a couple of things from requirements.txt and pipfile to make it compatible with linux
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment