3 ms·
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
by pmahoney 13y ago
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 http://www.youtube.com/watch?v=3soqhbnh0jY#t=35m22s
[2] http://nixos.org/nix/ http://nixos.org/nix/
- steveklabnik 13y ago> 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.