The short answer is: dunno.
Longer answer: This is where a little ruby and bundler knowledge would help to at least better understand what’s going on. Guessing a
gem install ... resulted in
google-apis-core-0.2.1 being installed at some point. Think this could have been previous to the
gem install terraspace command or maybe after. Inspected a
Gemfile.lock in a newly generated project:
google-apis-core (~> 0.1)
google-apis-core (~> 0.1)
It could have been another gem upstream that was installed on the devops machines a while back or afterwards. My understanding is that when
bundle install, or
bundle update runs, a dependency tree calculation runs. The commands can actually calculate different dependency trees. If there’s no current
Gemfile.lock, then the
bundle install calculation is freer to decide whether it can reuse existing gems that are already installed on the system.
The devil-are-in-the-details, it may also depend on ruby version, bundler version, etc. The net result is that the
Gemfile.lock can possibly not reflect dependencies available on the system. Think this is what probably happened. At least, that’s an attempted explanation.
In general, dependency resolution is a tough CS problem because different trees can satisfy the same constraints. As @ellisio mentioned, it surfaces elsewhere. Additional examples:
- ruby bundler and Gemfile.lock
- node, yarn, npm, yarn.lock, package.json
- python and requirements.txt often with pyenv
Found that there are nuances and quirks to each language that require some familiarity with the dependency system to understand. Maybe that’s why it feels like node and yarn deja vu.
One nuance is that a
gem install terraspace won’t update the
Gemfile.lock. But remember that both
gem install and
bundle update perform a dependency tree calculation. The tree gets resolved successfully, but it may be slightly different. IE:
gem install can use the existing
bundle update can update it to
google-apis-core-0.3.0 Different developers from all over the world work on these different pieces of the ruby ecosystem. So can see how commands can exhibit slightly different behavior. For most cases, and what others do in practice, is just run
bundle update and move on.
Also, terraspace actually has some error handling for bundle require errors already. But for some reason, the
handle_error method is not invoking. It’s defined here https://github.com/boltops-tools/terraspace/blob/a3d4310364efb4de2cfa0093fa1f3c5398b7d4a7/lib/terraspace/bundle.rb#L31 Again, maybe different bundler versions raise different exceptions. Unsure. There’s not enough context.
Anyway, updated the docs:
Also, note, this comes from a good place. Am hoping you bring a little more positive energy to the community. @ellisio is doing a great job trying to help. He’s using his own time, free of charge. There will always be ways to improve software and Terraspace. Constructiveness helps motivate me and others on this forum to help. Additionally, it fosters a healthy community. Again, this comes from a good place.
One thing that may help others help you in the future with these type of issues is providing a step-by-step reproduction. Saying nothing was done is often not the best way to elicit help. It’s more likely something did changed, we just don’t know what, and there’s unfortunately not enough context. Examples are also helpful. Letting others know ruby version, bundler versions, etc is helpful. The forums are a little more free form than the github issues to foster discussion, but there are so many things you can still do in the request to help.
And sometimes software mysteries are simply left unresolved. Life’s short. Restarting my computer and moving on rings a bell
Lastly, terraspace is it’s in early days. Terraspace was literally released a few months ago. Regardless, been getting very positive feedback and many thank yous from appreciative users impressed with the initial feature set. Will continue to harden terraspace. Wrapping my head around a few pretty cool future ideas for this year. Good things to come.