[Rubygems-developers] muti-packaging

TRANS transfire at gmail.com
Sat Mar 3 20:29:23 EST 2007


Hi--

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:

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.


More information about the Rubygems-developers mailing list