You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just had this conversation for the one billionth time, and we should definitely make this a section in the Applications guide so that people can find it by searching, and we can link to it instead of repeating it:
every single gem that has no version constraint on it means you are telling bundler it is required to consider every single version of that gem that has ever existed
if you are not okay with Bundler giving you version 0.1.0 of that gem, I recommend adding version constraints
also the number of possible versions involved increases the resolving time by something like n^2
so ruling out versions by adding version constraints speeds up the resolving by a huge amount
my usual pattern is to use rails at a single fully locked version, like “4.2.7.1"
and use all other gems at a movable tiny version, like “~> 3.2.12”
some gems that have especially trustworthy releases might get movable minor versions like “~> 3.2"
-but all of those things combined means bundle install or bundle update GEM can run really quickly
The text was updated successfully, but these errors were encountered:
I just had this conversation for the one billionth time, and we should definitely make this a section in the Applications guide so that people can find it by searching, and we can link to it instead of repeating it:
-but all of those things combined means
bundle install
orbundle update GEM
can run really quicklyThe text was updated successfully, but these errors were encountered: