On Thursday 29 May 2008 01:26:08 Suraj K. wrote:
would require gem creators to supply some kind of resource identifier in
the gem’s meta-data.
Let us assume that the aforementioned resource identifier is an
SCM-dependent URL to a project’s code repository. RubyGems would then
be responsible for (1) checking out the latest copy of the code
repository, (2) constructing a gem out of it, and (2) installing the
Make RubyGems pluggable, in some sense, if it isn’t already.
Simplest possible implementation that I can think of: Create a mostly
gem which depends on (or includes) everything required to interact with
SCM, and to run whatever is needed to build the gem file. After which,
replaces itself with the built gem (which, in turn, builds native
I don’t know enough about RubyGems to know if this can be made entirely
automatic, or if it’d end up being something stupid like:
sudo gem install foo-svn
sudo foo-svn bootstrap
(bootstrap script will automatically run ‘gem uninstall foo-svn’ on
installation of /var/some/where/foo.gem)
However, every system-level package manager I’ve worked with (dpkg, etc)
support for running arbitrary scripts at various points along the
installation. For example, I can install Ubuntu’s “msttcorefonts”
which, due to licensing strangeness, will actually download and unpack a
bunch of EXEs as part of the install.
I should probably go read more about RubyGems, though.
In contrast, if we were to make this feature fully SCM-independent, then
the aforementioned resource identifier would need to be something like a
URL to a ZIP file that contains the latest code for a particular
project. RubyGems would then be responsible for (1) fetching the ZIP
file, (2) constructing a gem out of it, and (2) installing the
I don’t like that, because then you’re downloading the entire project
time, and you’re not getting project metadata. It would be nice to be
have, say, /var/lib/gems/checkouts/foo, with which to develop the
patch against foo.