rubygems/rubygems — Issue #231: Break these up into digestable and (hopefully) parallelizable chunks
Author: zenspider
Created: 2011-12-14 04:06:25+00:00
State: open
Labels: status - accepted, type - feature

### Full Compatibility, Total Deprecation

## Motivation

* All gem resolution must take place via site_ruby/stdlib code. Anything else leaks the rubygems abstraction across boundaries that cannot easily be crossed in modern platforms.
* Make Bundler eat a face full of glass.
* Support new 'best practices' for packaging gems with applications, without losing mindshare and focus to Bundler.
* Expose people to the fact that RubyGems offers powerful isolation features already.
* Allow gem authors to easily support multiple platforms and implementations, which have conditional gem needs.
* Show people what the hell Ruby code is supposed to look like and how to work with other libraries, not against them.
* Take the opportunity this provides to roll out RubyGems API v2
* http://piratepad.net/up/MtnEXpJF31xbq+9yhOz2L0GFTok-.png

## Required:

* isolate gems (invisible and automatic update/cleanup of gems)
* accessible via api and gem cli
* accessible via rake
* reads "gemfile" like things for api and/or rake (or just use api).
* ensure subshells inherit gem environment
* multiple environments -- ie if statements allowed
* RubyGems API for plugging in new methods of satisfying missing gems. e.g. I want to make a plugin that fetches .gem files from a shared read-only cache. Make preventing HTTP requests a clean and easy thing to do. Note that this is not the same thing as just picking a new source gem server. Delegate fetch and install as requested.
* Added feature: install gems from system cache where possible. (a specific case of the above)
* do NOT support mixing of system gems and sandboxed gems.
* if we do, we ALWAYS have GEM_HOME be the isolated repo and we can
add the old GEM_HOME as GEM_PATH... but NOTHING more should be
supported. (but the above feature lets us not actually care).

## Options:

# :file:: Specify an Isolate file to +instance_eval+. Default is
# Isolate or config/isolate.rb, whichever
# is found first. Passing false disables file
# loading. If no Isolate or config/isolate.rb is found, the
# Bundler shim will look for a Gemfile.
#
# :path:: Where should isolated gems be kept? Default is
# tmp/isolate", and a Ruby version specifier suffix
# will be added if :multiruby is +true+.

## Non-Options:

# :cleanup:: Should obsolete gems be removed? Default is +true+.
#
# :install:: Should missing gems be installed? Default is +true+.
#
# :system:: Should system gems be allowed to satisfy dependencies?
# Default is +true+.
#
# :verbose:: Should Isolate be chatty during installs and nukes?
# Default is +true+.
#
# :multiruby:: Should Isolate assume that multiple Ruby versions
# will be used simultaneously? If so, gems will be
# segregated by Ruby version and platform. Default is +true+.

## In A Separate Bundler-compatibility Shim

* Autorequire. Unlike config.gems or other solutions, Isolate
expects you to be a good little Rubyist and manually
require the libraries you use. It could be interesting to basically extend the Kernel#gem feature-set to allow activating groups of gems. I'll think about it more.

* Support for Git or other SCMs. Isolate itself is focused on packaged,
released gems. A Git-remote plugin will fetch the repo, build it as a standard gem, and then toss the repo files. From there, Isolate will treat it like any other gem it has been told to package.