News for hackers. Stuff that matters.
Re:Announcing the new Rust package manager, Cargo by pmahoney on Monday March 17, 2014 @11:49PM (#7419984)
One issue I've run into (which may simply be ignorance) is the time consuming 'bundle install'. For example, I've updated some gems and run 'bundle update' on my development machine. I push that to the CI server, which must run 'bundle install' to install any new gems. But this seems to trigger the (NP-complete, last I checked [1]) dependency resolver yet again, even though I've already run it locally and my Gemfile.lock is newer than my Gemfile. Is there a way to skip it? Perhaps bundle just-blindly-install-the-gems-listed-in-Gemfile.lock?

Bundler in general is a nice tool, and Bundler + shared pile of gems is a nicer workflow than gemsets (though I am not a fan of "remembered options"; I'd rather make my own config file than forget that Bundler "remembered" my experimenting).

The more I think about Bundler, the more I wish that general purpose tools like Nix Package Manager [2] got more love. I've been playing around with using Bundler for the dependency resolution step, then Nix for the packaging and deployment steps (each app might have a separate Nix profile where it could install its particular set of gem versions), but there are missing pieces.

[1] http://www.youtube.com/watch?v=3soqhbnh0jY#t=35m22s [2] http://nixos.org/nix/

Re:Announcing the new Rust package manager, Cargo by steveklabnik on Monday March 17, 2014 @11:55PM (#7420014)
> the time consuming 'bundle install'.

Yup. This has gotten way faster, recent versions of Bundler include a -j. Also, the bundler-api project has been steadily working on making this faster. Without getting into the details, let's say the gems format and API does not make doing this efficiently easy.

> But this seems to trigger the (NP-complete, last I checked [1]) dependency resolver yet again,

It does not. It _does_ check to ensure that what's in the Gemfile matches what's in the Gemfile.lock, though.