From: David Masover Date: 2008-05-29T18:37:06+09:00 Subject: Re: ruby wish-list On Thursday 29 May 2008 01:26:08 Suraj Kurapati wrote: > David Masover wrote: > > On Wednesday 28 May 2008 20:51:15 Suraj Kurapati wrote: > >> Roger Pack wrote: > >> > gem install package_name --checkout_latest_svn_trunk_and_build_it > >> > >> Not everyone uses Subversion. :) > > > > No reason it has to be SCM-specific. > > From my understanding of the problem, implementing this kind of feature > 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 > constructed gem. Make RubyGems pluggable, in some sense, if it isn't already. Simplest possible implementation that I can think of: Create a mostly static gem which depends on (or includes) everything required to interact with the SCM, and to run whatever is needed to build the gem file. After which, it replaces itself with the built gem (which, in turn, builds native extensions, etc etc). 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 successful installation of /var/some/where/foo.gem) However, every system-level package manager I've worked with (dpkg, etc) has support for running arbitrary scripts at various points along the installation. For example, I can install Ubuntu's "msttcorefonts" package, 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 > constructed gem. I don't like that, because then you're downloading the entire project every time, and you're not getting project metadata. It would be nice to be able to have, say, /var/lib/gems/checkouts/foo, with which to develop the occasional patch against foo.