Git reference inside a source block changes .lock file unexpectedly

[craig-day]

If you reference a git repo inside of a source block, any gems after said git reference will be changed in Gemfile.lock.

Example

Starting project, with the Gemfile and Gemfile.lock as expected:

https://github.com/craig-day/bearded-nemesis

I have the base gems for a simple rails app in my Gemfile, then I also want to use https://rails-assets.org for my asset management, so I added a source block at the bottom to do so. All is fine and behaving expectedly.

Example problem branch:

https://github.com/craig-day/bearded-nemesis/tree/broken_gemfile

This example seems like a silly thing to do, but it illustrates the point well. I added a gem with a git reference to the source block. If you look at the diff for Gemfile.lock (here) you will notice that it removed the ! from all of the gems referenced after the git reference.

To put this into context, I can explain a real situation. At work we use a private gem server to host published gems, and Github to manage our git repos. In the normal situation, gems will get published to the gem server and all is well. If I want to test a gem feature branch for example, the simplest thing to do would be to tell that gem to reference the branch on Github. This works fine, but it makes unnecessary changes to the lock file. I would expect referencing git to only change the single gem I changed.

[richbowen]

I have tested and confirmed the behaviour illustrated above.

From my understanding the source block allows for gems to be retrieved from a specific source, in this case https://rails-assets.org. If the above is the case then it would seem appropriate to declare gems that will be retrieved from that source alone within the source block. However, you have a gem being declared from another source in a source block. Is there a particular reason for this?

I think this would solve your issue.

source 'https://rails-assets.org' do
  gem 'rails-assets-bootstrap'
  gem 'rails-assets-angular'
  gem 'rails-assets-leaflet'
end

gem 'soft_deletion', git: '[email protected]:grosser/soft_deletion.git'

None the less whatever your reason I guess what should happen is that the gems should be retreived from the reals-assets.org source until it meets the soft_deleteion gem for which it will change source and retrieve it from the git source specified. After that however, it doesn't seem to go back to using the rails-assets.org source. It seems to break the source block and go back to using the default source of rubygems.org.

[craig-day]

@rgb-one I agree it is a very weird case, but I think my last paragraph is the best example I can give. Normally a gem will come from the source, but for some development testing I might want to reference it to the a git branch rather than it come from the source. It would be nice to just be able to add the git source without having to move the gem. Your case does solve the issue, just wanted to bring up some expected behavior even if it is for an odd use case.

[richbowen]

Ah it seem I did some selective reading. I reread the last part of the OP and I understand your use case now.

Maybe the desired behaviour could be achieved using groups. So if group is :development then it woud retrieve from the git source, otherwise it would use the rails-assets.org source.

[segiddins]

No, this is very clearly a bug. Thanks for reporting it, @craig-day!

[agis]

What actually happens is that any gem that's defined inside a source block and contains a custom source (eg. a git or path option), causes subsequent gems that are inside the same source block to be fetched from the default rubygems source (ie. rubygems.org).

Hopefully, #3978 fixes this properly.

cc @indirect @segiddins