I'm trying to get an old version from a repository using bundler.
For instance, in my Gemfile I have:
...
gem "custom-metrics", "~> 0.14.0", git: "https://gitlab.custom.co/gems/custom-metrics.git"
...
This is properly installing the version 0.14.0. Then I pushed a 0.14.1 version in the dependency repository, and it's still the same, as expected.
In the dependency, I'm setting the version in my .gemspec file as:
Gem::Specification.new do |spec|
spec.name = "custom-metrics"
spec.version = 0.14.0
...
end
If I now push a 0.15.0 version, it would stop working. In this case, I have to specify the ref: to the previous commit. So it seems it's not that bundler can't install the version, but that it only looks for versions in the last MINOR version (in this case, it would be in 0.15.*)
I couldn't find any doc that confirms my hypothesis.
> Am I missing something?
> Would it be possible to specify a version and be sure that bundler will always find it?
When loading a gem directly from a git repository, then Bundler loads exactly the version that it find in the defined branch, at the ref or tag.
When you define that a specific version of the gem should be used, then Bundler will check if the version of gem found in the repository matches that condition.
Therefore, you likely do not want to simply install the latest available version of a gem directly from a main branch from GitHub. But instead defining to install from a specific branch, tag, or ref might be easier to manage.
How to install gems from git repositories from the Bundler docs.
Related
I have a gem that I one of the owner/authors (hyperloop) that depends on another gem (opal-rails) which depends on another gem (opal-jquery).
All gems depend on the gem opal. The problem is the current released version of opal-query is locked to an older version of the opal gem.
The version of opal-jquery on master is okay. For whatever reason the author(s) have not pushed ruby gems, so I have to work around this.
The work around is that I have to say
gem 'hyperloop'
gem "opal-jquery", git: "https://github.com/opal/opal-jquery.git", branch: "master"
in the application Gemfile.
I am hoping somebody can give a workaround that could be embedded in the hyperloop gemspec, so that the problem is taken care of there.
I thought if I added
gem "opal-jquery", git: "https://github.com/opal/opal-jquery.git", branch: "master"
to the hyperloop Gemfile this would take care of it, but apparently not.
There isn't really a way to manage the dependencies of your dependencies. You have 2 options here:
1) Use an older version of opal
2) Clone the opal-jquery gem and modify its Gemfile, pointing to the version of opal you want it to use, then, in your Gemfile, point the opal-jquery gem to pull from your cloned version of the repo
Neither of these is really ideal and you'd have issues if you ever decided to upgrade to a newer version of opal-jquery if you go with the second route
I tried to modify an existing gem and forked the git repository.
I added some commits and pointed bundler to my GitHub repository.
bundler update does recognise the change and downloads my version of the gem.
Anyway when I try to launch the application which depends on that gem (testkitchen) my changes aren't available. And when I delete the official version of the gem my version is not found/used and the app fails.
The weird thing is that all the official gems are installed to /var/lib/gems and my version goes to ~/.bundler
gem environment also shows up the correct directories
- GEM PATHS:
- /var/lib/gems/2.2.0
- /home/ansible/.bundler/ruby/2.2.0
I'm not using rvm or similar. Am I doing something wrong?
As #matt pointed out I forgot to add bundle exec to my commands.
I am working on a gem and it's on github.
When I include the gem in an application, do a capistrano deploy, and (on the server) run:
bundle outdated
I see:
* authengine (0.0.1 d8baa49 > 0.0.1 de43dfa)
which tells me that a more recent commit is available. Why doesn't the bundle update (part of capistrano deploy) pull the more recent version? There is no version constraint in the Gemfile of the host application, and anyway they have the same version number, just different commits.
Even if I log into the server and run
bundle update authengine
I get the same "outdated" result afterwards.
What am I missing here?
One thing I've found that can cause this is if other gems in the bundle make requirements on gems by version that are incompatible. Bundler tries to reconcile these by selecting versions of gems such that their requirements can all be satisfied. The result is that it quietly refuses to update gems.
The way to check this is to set an explicit version requirement in your Gemfile. Something like
gem "authengine", "> 0.0.2" #(you'll need to bump the version to make this work)
#or
gem "authengine", :ref => "d8baa49"
Then run
bundle update authengine
You should see something like (this is taken from my particular case):
Bundler could not find compatible versions for gem "json": In
Gemfile:
chef (> 10.8) ruby depends on
json (<= 1.6.1, >= 1.4.4) ruby
logical-construct (>= 0) ruby depends on
json (1.7.5)
So, in my case it's a problem with explicitly requiring a newer version of json.
The author, André Arko, stated in 2014 that:
The Bundler resolver is definitely a work in progress, and we adjust
the tradeoffs between specific versions and resolving quickly based on
user feedback.
Bundler has consistently not provided the newest possible version of
every gem for the entirety of its existence, and it does result in a
lot of tickets being opened. In most cases, it turns out to be the
result of Bundler having to pick between the newest version of one gem
or a different gem, and Bundler picks the gem the user doesn’t care
about having the newest version of. That’s why it’s so important to
make your Gemfile version requirements accurately reflect your actual
requirements.
I recognize that your assumption that Bundler would give you the
newest possible version seemed valid at the time, but the docs only
say that you will get a version that meets your requirements, not the
latest. Is there anywhere we could expand the docs to make it clearer
that the newest versions of everything simply isn’t feasible?
What is the output returned when you run bundle update authengine? Does it actually say it updated the gem? Or does it ignore the gem?
You can try using the --source parameter to specifically tell Bundler to use the git repository. That, or your
bundle update authengine --source https://github.com/mustardseeddatabase/authengine.git
Also, when unexpected things like this happen, I like to clean up my gemlist in general. It could be that you still have older versions of the gem laying around, not using in bundler.
So you could do:
gem list
gem check
gem cleanup
Or do a complete reinstall
gem uninstall authengine
bundle install
In my GEM file i have:
gem 'shoulda'
But I would like to use the latest version. How can I do it ?
This will use the latest version available as a gem. If a new version of shoulda was released since you wrote it in Gemfile, you will have to use bundle update shoulda, so it will get updated (according to the version specified in your Gemfile, which in your case means the latest available).
You can also set it so it use the git repository as source, and then you'll truly have the latest version. I suggest you read gembundler manual for more on this topic
I have a Gemfile with a private git repo in the following format:
gem 'magic_beans', :git => "git#git.example.com:magic_beans.git', :branch => 'super_beans'
When I bundle install, the Gemfile.lock locks it to a specific SHA revision.
Can I get bundler to always check and use the latest SHA commit and/or update the Gemfile.lock? Notice that when I push updates to the super_beans branch I am not modifying the gem version.
Ideally, every time I run bundle it would check upstream git repo for a newer SHA revision of the branch.
This isn't how bundler works.
The point is to allow seamless versioning of dependencies.
(particularly so you know exactly what version of the code is deployed at any given time).
If want the latest version, you should just run.
bundle update magic_beans
This is exactly the same functionality as if you just say
gem "rails"
I'd suggest though, if you have a range of specific things you want to update
then add a custom binary (say an executable file named bundle_update)
#!/usr/bin/env bash
bundle install
bundle update magic_beans
Then just do a ./bundle_update when you want to update these things.
You can run bundle update to update all or specific gems to their latest available version, as stated in the docs.
Would that help?
After searching through the documents I finally found the magic way to do this:
bundle update magic_beans --source magic_beans
That is to update the magic_beans gem only, but not to touch other locked gems. The doc about this is: http://bundler.io/man/bundle-update.1.html
delete .gemlock is what worked for me :/