Hacker News Reader

Comment by examancer | Hacker News Reader

The main reason this is better is explained in the third paragraph in the README: Deterministic builds. You can specify target versions in your Pipfile, while your Pipfile.lock will contain the actual exact versions pip installed (even the exact git commit) so if your app is built on another machine you know the libraries are exactly the same, preventing slight version differences from causing you problems without requiring you to be ultra-specific in your dependencies.

Another benefit is named groups, which allow you to more succinctly specify dependencies for various environments (dev/test/production/etc.) Along with this you get the benefits of the lock file so you can be assured the subset of libraries you use in production will be the exact tested libraries you use in your larger dev/test environment.

View on HN

deterministic builds are good, but i think the issue people are seeing with this is that it's like setup.py, in that it's not easily parsable without the full python interpreter. We could already have a requirements.lock.

in fact, there's already a library for this called pip-tools (https://github.com/nvie/pip-tools) that generates a requirements.txt (the lock file) from a requirements.in (your direct dependencies)

Worth pointing out that the builds will be deterministic only in regards to Python libraries. For anything else (e.g. libxml) different machines might still have completely different versions, and behaviors, so determinism goes out the window.

To fix that, you'd need something like Nix.

How is the Pipfile.lock distributed? Is it intended to be checked into source control alongside the Pipfile? If so, how would that help someone pip install my Python project (say from pypi) using that Pipfile.lock and get the benefits of a deterministic build?

Yes, source control.

Installing the project would cause it to be built from the lock file (assuming the Pipefile hasn't changed). This will mean your users won't get "some version" of a library you depend on between verion 1.0 and 2.0 or whatever range you specified. They'll get the exact package you last successfully used and checked in yourself, right down to the git commit if applicable.

Once you modify the Pipfile then pip will resolve your dependencies and try to make the specified changes by adding/removing/upgrading packages. If Pypa continues following bundler conventions this will be done by making the fewest changes possible from your existing versions in your lock file. You'll also have an upgrade mode where pip will rebuild you project from the Pipfile looking for the most recent versions of all libraries or a specified library within your specified version ranges. When done and your app/tests are working, check in the new version and you can ensure all your users/environments will be able to upgrade cleanly.

Depends on the use. For a library, it doesn't need to be distributed at all, since the application that's using the library will eventually dictate the actual versions of dependencies (so it can play nicely with other libraries). For an application, yes: you commit it along-side the pipfile, and re-generate the lock file when you upgrade things.

https://caremad.io/posts/2013/07/setup-vs-requirement/ covers it pretty well. Or https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... for a fantastic read and a LOT more context.

The question is... How is this better than running 'pip freeze > requirements.lock' whenever you decide to make a new library (or version) official?

Reply on news.ycombinator.com