6 ms·

I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.

by mbell 11y ago

sync 11y ago
Mix, Erlang's package manager (used by Phoenix / Elixir) Cargo, Rust's package manager Meteor
- SEMW 11y ago
  > Mix, Erlang's package manager (used by Phoenix / Elixir) Slight nitpick: Mix is part of Elixir, I've never seen a (non-elixir) erlang project that use it. Don't think erlang has an equivalent officially blessed tool, but the most popular one is rebar / rebar3. (While I'm nitpicking: mix and rebar are more build & dependency managers; mix uses hex for package management. I believe rebar3 can also use hex. In ruby terms, mix ~ bundler (among other things); hex ~ rubygems).
geerlingguy 11y ago
Composer (PHP) too.
deleted 11y ago
[deleted]
strmpnk 11y ago
These come to mind: rebar3 (Erlang), mix (Elixir), composer (PHP), elm-package (via elm-stuff/exact-dependencies.json).
stormbeta 11y ago
You get a similar effect for free with any language whose community defaults to non-floating transitive dependencies, e.g most JVM languages.
- technomancy 11y ago
  Indeed; a lockfile is just a workaround for the problem of "just give me whatever" dependency declarations. Solve the problem at the root rather than piling hacks on it.
  - dasil003 11y ago
    I'm not 100% sure from your comment, but are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? As someone writing a lot of ruby, "give me whatever" is analogous to "give me the latest unless I specify otherwise", which I consider to be a very good default. It keeps me up to date with security issues, and incompatibilities between libraries that the respective maintainers resolve amongst themselves with a minimum of manual work.
    - technomancy 11y ago
      > are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? Yes, this is the way that Guix and Leiningen and rebar3 and a bunch of other things work, and it is wonderful. Pulling in new code without you asking is a fine idea for something like apt-get where you have a huge team doing QA on the entire system working together before it even hits your repositories, but for most package managers, the dev team is the one doing the testing, and upgrades should be done only with great care. It does mean you have to watch for security updates, but this is true of all package managers.
      - dasil003 11y ago
        If you want to do this in ruby you can just specify a version manually. If you don't, you still get versions frozen by default with Gemfile.lock. It doesn't pull in anything automatically—by default you get no updates, you can choose to update a single dependency, or the whole thing if you want to verify it works on the latest (useful for libraries for instance). I'm not sure I see the downside. FWIW I have been doing ruby for over a decade now, and I hold up Bundler as one of the great success stories of open source, and it is one of the reasons I hold Yehuda Katz in high regard, in that he was able to solve a really big problem in the community and hammer it into shape aggressively over a period of two years with a lot of doubters and naysayers (even Rubygems core was against Bundler for a long time), until it finally got so solid for so many use cases (libraries vs apps, private vs public, development vs deployment, etc, etc) where it solved nearly everyone's problems in such a solid way that everyone adopted it.
juandazapata 11y ago
Cabal (Haskell) too.
josegonzalez 11y ago
I try and push devs to do pip freeze > requirements.txt Which has a similar effect.
- jonafato 11y ago
  This is a good start, but it has issues. You probably don't want all of your locally installed packages in a requirements.txt file. Instead, they should be curated. I've been using pip-compile [0] for a while now (see the author's blog post [1] for a detailed explanation) and have become a big fan of it. With this model, you should enumerate only what your application uses directly and let pip-compile convert this list to a full version-locked requirements.txt. (Shameless plug: I also wrote a bit about why this is the best currently available option for specifying Python dependencies [2].) [0] https://github.com/nvie/pip-tools#example-usage-for-pip-compile https://github.com/nvie/pip-tools#example-usage-for-pip-comp... [1] http://nvie.com/posts/better-package-management/ http://nvie.com/posts/better-package-management/ [2] https://www.jonafato.com/2015/12/15/Rethinking-requirements-txt https://www.jonafato.com/2015/12/15/Rethinking-requirements-...
  - jsjohnst 11y ago
    If one uses virtualenv as a Pythonista should, then your keep point doesn't carry much weight. That said, this looks cool and I'll check it out.
    - jonafato 11y ago
      This should be used with virtualenv, not as an alternative to it. I have a bunch of libraries and tools in almost all of my virtual environments that are not application dependencies and have no business being installed in my production environment (e.g. bpython, tox, flake8, and neovim). This approach also handles things like a dependency being dropped gracefully (if some library no longer needs a dependency, it magically gets removed from your locked requirements.txt next time you compile requirements.in). Python's package management tools are making great strides (see pip's recent peep-style hash checking support), and pip-compile is a big win in that category in my opinion.
rodgerd 11y ago
And it's so awesome when you discover devs have used lockfiles to leave you stuck on known-insecure gems instead of updating their fucking code to support the newer patched version.
- mikekchar 11y ago
  Which is still better than having your server crash due to a bug in a dependency of a dependency that got updated without your knowledge when you deployed something trivial. It has happened to be more than once.
theknarf 11y ago
PHP have a package manager called Composer which have a lock file.
deleted 11y ago
[deleted]

I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.

by mbell 11y ago

I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.

sync 11y ago

Mix, Erlang's package manager (used by Phoenix / Elixir) Cargo, Rust's package manager Meteor

SEMW 11y ago
> Mix, Erlang's package manager (used by Phoenix / Elixir) Slight nitpick: Mix is part of Elixir, I've never seen a (non-elixir) erlang project that use it. Don't think erlang has an equivalent officially blessed tool, but the most popular one is rebar / rebar3. (While I'm nitpicking: mix and rebar are more build & dependency managers; mix uses hex for package management. I believe rebar3 can also use hex. In ruby terms, mix ~ bundler (among other things); hex ~ rubygems).

geerlingguy 11y ago

Composer (PHP) too.

deleted 11y ago

[deleted]

strmpnk 11y ago

These come to mind: rebar3 (Erlang), mix (Elixir), composer (PHP), elm-package (via elm-stuff/exact-dependencies.json).

stormbeta 11y ago

You get a similar effect for free with any language whose community defaults to non-floating transitive dependencies, e.g most JVM languages.

technomancy 11y ago
Indeed; a lockfile is just a workaround for the problem of "just give me whatever" dependency declarations. Solve the problem at the root rather than piling hacks on it.
- dasil003 11y ago
  I'm not 100% sure from your comment, but are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? As someone writing a lot of ruby, "give me whatever" is analogous to "give me the latest unless I specify otherwise", which I consider to be a very good default. It keeps me up to date with security issues, and incompatibilities between libraries that the respective maintainers resolve amongst themselves with a minimum of manual work.
  - technomancy 11y ago
    > are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? Yes, this is the way that Guix and Leiningen and rebar3 and a bunch of other things work, and it is wonderful. Pulling in new code without you asking is a fine idea for something like apt-get where you have a huge team doing QA on the entire system working together before it even hits your repositories, but for most package managers, the dev team is the one doing the testing, and upgrades should be done only with great care. It does mean you have to watch for security updates, but this is true of all package managers.
    - dasil003 11y ago
      If you want to do this in ruby you can just specify a version manually. If you don't, you still get versions frozen by default with Gemfile.lock. It doesn't pull in anything automatically—by default you get no updates, you can choose to update a single dependency, or the whole thing if you want to verify it works on the latest (useful for libraries for instance). I'm not sure I see the downside. FWIW I have been doing ruby for over a decade now, and I hold up Bundler as one of the great success stories of open source, and it is one of the reasons I hold Yehuda Katz in high regard, in that he was able to solve a really big problem in the community and hammer it into shape aggressively over a period of two years with a lot of doubters and naysayers (even Rubygems core was against Bundler for a long time), until it finally got so solid for so many use cases (libraries vs apps, private vs public, development vs deployment, etc, etc) where it solved nearly everyone's problems in such a solid way that everyone adopted it.

juandazapata 11y ago

Cabal (Haskell) too.

josegonzalez 11y ago

I try and push devs to do pip freeze > requirements.txt Which has a similar effect.

jonafato 11y ago
This is a good start, but it has issues. You probably don't want all of your locally installed packages in a requirements.txt file. Instead, they should be curated. I've been using pip-compile [0] for a while now (see the author's blog post [1] for a detailed explanation) and have become a big fan of it. With this model, you should enumerate only what your application uses directly and let pip-compile convert this list to a full version-locked requirements.txt. (Shameless plug: I also wrote a bit about why this is the best currently available option for specifying Python dependencies [2].) [0] https://github.com/nvie/pip-tools#example-usage-for-pip-compile https://github.com/nvie/pip-tools#example-usage-for-pip-comp... [1] http://nvie.com/posts/better-package-management/ http://nvie.com/posts/better-package-management/ [2] https://www.jonafato.com/2015/12/15/Rethinking-requirements-txt https://www.jonafato.com/2015/12/15/Rethinking-requirements-...
- jsjohnst 11y ago
  If one uses virtualenv as a Pythonista should, then your keep point doesn't carry much weight. That said, this looks cool and I'll check it out.
  - jonafato 11y ago
    This should be used with virtualenv, not as an alternative to it. I have a bunch of libraries and tools in almost all of my virtual environments that are not application dependencies and have no business being installed in my production environment (e.g. bpython, tox, flake8, and neovim). This approach also handles things like a dependency being dropped gracefully (if some library no longer needs a dependency, it magically gets removed from your locked requirements.txt next time you compile requirements.in). Python's package management tools are making great strides (see pip's recent peep-style hash checking support), and pip-compile is a big win in that category in my opinion.

rodgerd 11y ago

And it's so awesome when you discover devs have used lockfiles to leave you stuck on known-insecure gems instead of updating their fucking code to support the newer patched version.

mikekchar 11y ago
Which is still better than having your server crash due to a bug in a dependency of a dependency that got updated without your knowledge when you deployed something trivial. It has happened to be more than once.

theknarf 11y ago

PHP have a package manager called Composer which have a lock file.

deleted 11y ago

[deleted]