transfire at gmail.com
Sat Mar 3 20:29:23 EST 2007
On 3/3/07, Eric Hodel <drbrain at segment7.net> wrote:
> On Mar 3, 2007, at 12:22, TRANS wrote:
> > (Posted this to Ruby-talk then realized it would be better here)
> > Any chance of getting RubyGems to support the packages/ dir that's
> > supported by setup.rb? I currently have to run a custom staging task
> > before I can create a gem for a project that has subprojects.
> What are these packages supported by setup.rb?
>From the setup.rb manual:
Creating Multi-Package Archive
setup.rb can handle an archive which includes multiple PACKAGEs.
setup.rb requires the archive is structured as below:
packages/ <--- fixed name
tmail/ <--- tmail package
raccrt/ <--- raccrt package
strscan/ <--- strscan package
amstd/ <--- amstd package
Can't say I've ever been fond of the dir name 'packages' but that's
what Minero choose. In anycase, it allows one to break up a large
project into parts that might be useful on ther own.
> > Alternatively, RubyGem multi-packages might be nice. Installing a
> > multi-package would install dependent packages, but would behave as if
> > it were a single package.
> Adding an uninstall flag that would install a gem and any of its
> unused dependencies would be a more-general solution.
Hmm... It's largely a perceptual difference from the end users point
of view. If the end user has to say 'y' to every dependency then there
is a barrier of acceptance of sorts. This is still true for the
special flag on the command line --"say yes to all", too. The tendecy
is to use the shortest command so even a small flag like '-y' can
create this perceptual barrier.
Maybe it should be the other way around and the deafult behavior
should be '-y'. After all if you trust a gem enough to install it
wouldn't you trust the dependencies it relies on too?
> > Another thought, is to create a "GemCruncher" that could take a set of
> > gems and merge them into a single gem.
> Write one and we'll consider merging it, but I don't think anybody
> else has requested such a feature.
Okay, I'll consider it.
More information about the Rubygems-developers