Is there a way to prevent authentication against a source inside an excluded group?

59 views
Skip to first unread message

Chris Knowles

unread,
Jun 29, 2016, 10:29:04 PM6/29/16
to ruby-bundler
I have a slightly odd use case in which I need to bundle install a set of dependencies but exclude one specific private one that comes from a separate source. I still need the private one in the Gemfile for installation during a different process for the same project. I tried to set it up in a group like this:

group :private do
  gem 'private_gem', '~> 1.0.0', source: 'https://private_repo.com'
end

And then perform this bundle command:

bundle install --jobs 20 --retry 3 --without private

However, with bundler 1.12.5 it seems to authenticate against all sources prior to the install regardless of whether they are excluded or not. Is there any way around this? I had a look through the docs but didn't spot anything and I'm reasonably new to bundler.

Andre Arko

unread,
Jun 29, 2016, 10:56:05 PM6/29/16
to ruby-bundler
Hi Chris,

All version of Bundler must authenticate against every source, because Bundler has to make sure every gem is compatible, so it has to download the gemspec for every gem. It won't install the gem, but it absolutely has to be able to access the source for it to be possible to install.

Chris Knowles

unread,
Jun 30, 2016, 2:53:32 AM6/30/16
to ruby-bundler
Thanks Andre, that sort of makes sense. Since I'm new to bundler I'm not sure why it is trying to assess the compatibility of a gem that I'm specifically ignoring.

Interesting if I set the private repo mirror to rubygems then the install goes through without issue:

bundle config mirror.https://private_repo.com https://rubygems.org

Obviously that's prone to hijacking should there be a gem with the same name on rubygems.org so not useable in practice. However, the gem I'm trying this with does not have a match in rubygems.org and the installations goes through successfully. Perhaps bundler ignores missing gems when it tries to work out the compatibility?

André Arko

unread,
Jun 30, 2016, 3:40:37 AM6/30/16
to ruby-b...@googlegroups.com
Even though you are ignoring the gem, Bundler must make sure that it _could_ be installed. If Bundler didn’t check the compatibility at all times, you could ignore the gem now and then stop ignoring it later—and not be able to install it, ever.

I just tried to install a gem that doesn’t exist on rubygems.org using the trick that you described, and I’m getting an error. I suspect that Bundler isn’t ignoring the gem, it’s finding a copy of that gem (possibly already installed on your machine?) and using that copy.

--
You received this message because you are subscribed to the Google Groups "ruby-bundler" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-bundler...@googlegroups.com.
To post to this group, send email to ruby-b...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-bundler.
For more options, visit https://groups.google.com/d/optout.

Chris Knowles

unread,
Jun 30, 2016, 5:12:55 AM6/30/16
to ruby-bundler
Thanks for explaining, I understand. My preference in this case is let the user accept that scenario, although I can understand the arguments against it. In my case if bundler cannot install later that's actually fine as the CI will catch that. Since it's a private dependency we can update as appropriate. I suppose the scenario is a bit like optionalDependencies in NPM although not quite the same.

Well that is strange! To briefly explain a bit more, I'm doing this as part of a Docker container build. I thought you were probably right and it had been cached somewhere. Slightly off topic but I cleared out all local Docker volumes, images and containers plus checked any volumes mounted which means I could do an entirely fresh build. The bundler cache is not mounted which means it sits inside the container. I rebuilt from entirely fresh and it works so I'm not sure why yours did not. I went one step further and completely removed the private source from my machine just in case the build had access to it somewhere I haven't spotted, but it still works. I'm using a Gemfile.lock if that makes any difference?

In the logs for the build, I see these logs lines three times each which seems to indicate the mirror config is being acted upon:
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Fetching dependency metadata from https://rubygems.org/

No log lines for the private repo.

I also reconfirmed that if I remove the mirror config line from the build, it immediately fails with the standard Authentication is required message.
Reply all
Reply to author
Forward
0 new messages