The answer is 42

I have been working on an internal project recently to plot the gem interdependencies of a project that has very limited version requirements.

gem 'somegem'
gem 'somegem-with-some-extended-feature'
gem 'someothergem'
gem 'somegem-with-something-thats-broken-no-really'

I can plot the interdependencies of this project, I can take a look at the Gemfile.lock and at a given point in time (at the point it was last bundled) that the project had those dependencies. This includes the sub-dependencies (which as we all know can be a laundry list). But this is a goal post that changes all the time. If I want to plot over time what a projects dependencies are it needs to be against something static. But in an ecosystem where software is being updated constantly what are those checkpoints? Gemfile.lock?

If I am constantly bundling in development the Gemfile.lock is always changing. If I commit my repo without a Gemfile.lock at all, the state of the dependencies is highly unpredictable. So for a project for sanity we lock it down and commit our Gemfile.lock so we know what we are deploying and it's predictable and can be deployed with a degree of confidence in what we are deploying in terms of bundled gems.

But suppose this was a third-party gem that we are building. There is no Gemfile.lock or not one we should be committing. We have a fluid set of dependencies, the inter-dependencies can change all the time with every release of our above gems and their own interdependencies. Sure, when our gem is embedded in a project, that project has a Gemfile.lock, etc each project should be have the same versioned gem dependencies no matter how many instances of that project are deployed. We can capture the state of the dependencies on project by graphing each Gemfile.lock over time.

But when it comes to gems that don't have a Gemfile.lock this is forever changing and there is no fixed checkpoint at all. You can't rely on a say a semantic version update because any unlocked dependencies still change over time.

This begs the question, what exactly am I trying to graph or even prove. At the very least it proves that the we're trying to graph and understand our ecosystem and we can't do that without bringing it into some kind of order first.

I did learn today that you can discretely update a single gem without updating it's dependencies. I wonder if we can limit this conservative approach to a group of gems from a single source.

bundle update --conservative m3ta

My project started as a fairly simple objective but that objective has just raised more questions than I think it can answer without further clarification or acceptance that the result will be flawed. So I can conclude the answer is 42.