Break these up into digestable and (hopefully) parallelizable chunks #231

Closed
zenspider opened this Issue Dec 14, 2011 · 1 comment

Comments

Projects
None yet
4 participants
Contributor

zenspider commented Dec 14, 2011

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.

wilson was assigned Dec 14, 2011

wilson was unassigned by krainboltgreene Jan 1, 2016

Contributor

copiousfreetime commented Jan 19, 2016

With the eventual merge of rubygems and bundler, is may no longer be applicable. Marking as abandoned for now and probably closing in the near future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment