Hi--
On 3/3/07, Eric Hodel <[EMAIL PROTECTED]> 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:
PackageTop/
setup.rb
packages/ <--- fixed name
tmail/ <--- tmail package
bin/
lib/
ext/
data/
conf/
man/
test/
raccrt/ <--- raccrt package
bin/
lib/
ext/
data/
conf/
man/
test/
strscan/ <--- strscan package
bin/
lib/
ext/
data/
conf/
man/
test/
amstd/ <--- amstd package
bin/
lib/
ext/
data/
conf/
man/
test/
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.
Thanks,
T.
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
