rubygems-uri-namespacing.md

RubyGems and Namespacing

Here's what my Gemfile should be:

source 'https://rubygems.org'

source 'https://gem.fury.io/eventide' do
  gem 'eventide'
end

However, this is what it must be:

source 'https://rubygems.org'

source 'https://gem.fury.io/eventide' do
  gem 'eventide'
  gem 'process_host'
  gem 'attribute'
  gem 'clock'
  gem 'configure'
  gem 'controls'
  gem 'schema'
  gem 'serialize'
  gem 'settings'
  gem 'telemetry'
end

That means users must know the internals of the dependency graph of the Eventide project - which is not what they should be required to do.

The solution to this would be to allow direct namespacing of Gem dependencies as declared in the gemspec.

For example:

Gem::Specification.new do |s|
  s.name 'eventide'

  # ...

  s.add_runtime_dependency 'https://gem.fury.io/eventide/process_host'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/attribute'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/clock'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/configure'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/controls'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/schema'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/settings'
end

Where dependencies of dependencies can also be specified directly via their specific namespace:

Gem::Specification.new do |s|
  s.name 'schema'

  # ...

  s.add_runtime_dependency 'https://gem.fury.io/eventide/serialize'
  s.add_runtime_dependency 'https://gem.fury.io/eventide/telemetry'
end

This should be entirely optional. The user can make an informed decision about which option to use based on the inherent trade offs of binding to a URI, or just the Gem name, relying on external factors to dictate the namespacing (ie: RubyGems' sources list, Bundler, etc).

Caveats

Addressing Gems as URIs requires that the maintainer of a project keep links to their gems functional, and the Gem server operational and available.

This is no different than any addressable resource on the internet, and it's one of the cornerstones of HTTP that make the web as we know it useful.

If a project owner allows their project to go fallow, there's a potential for dependencies to become unavailable.

In such a case there would be a dependency on an obsolete, or dead project. While this is fine and good - especially if the existing code is still useful - the community and eco-system would immediately respond as a de-centralized, web-like organization would: someone would mirror the missing gem.

Of course this would result in some consternation - but no more so than the on-going consternation over taking a dependency on a dead project, and one that would have been known to become unavailable from its original source at some point.

In practice and in the wild, we deal with this all the time. HTTP's usefulness is predicated on the contract the URIs provide, and the re-negotiation of physical location of resources via redirects and via the indirection that DNS provides.

Because we are already familiar with the trade offs as well as the solutions and countermeasures for de-centralized availability with an HTTP network, we can successfully resolve any issues with unavailable resources the way we have been doing for almost two decades.

While there may be issues of lack of availability for some obsolete gems, they will be few and far between. And those projects that are dependent on unavailable parts have made the decision to continue to do so, and the onus is upon them to resolve issues inherent in these kinds of decisions with existing and known countermeasures (eg: gemstash, local mirrors, etc).