Re: A concrete solution to RubyGems' repackageability problems

On 10/17/05, Mauricio Fern疣dez <[e-mail]> wrote:
> > > RubyGems developers
> > > * interaction with repackagers done through Package.rb, which has been
> > >   designed and implemented based on the feedback from experienced repackagers
> > > * less work ;-) much of the TODO
> >
> > Didn't you say the repackaging problems concerning RubyGems were about
> > content, not format?
>
> The most annoying problems are those that require patches to the source code.
> There are other comparatively minor annoyances Package would also help to avoid.
>
> We can promote good practices that help repackagers and end users from within
> RubyGems. RubyGems' packaging process can guide the upstream developer so the
> software he writes works both with and without RubyGems. Package would play
> that role.

That sounds like a very positive step.  I like to see bits of RubyGems
be outsourced so its not going off in its own direction so much.  And
I think it's terrific to encourage, through software, better packaging
practices in such a reusable fashion.

> > For example, if I put the following code in a library file:
> >
> >   require_gem 'gmailer', '> 0.1.0'
> >
> > and then package it as a gem, will repackagers complain?
>
> The major problem with require_gem was its non-declarative nature due to
> autorequire. Once the latter goes (as decided by the RubyGems team IIRC) and
> require_gem is renamed to use_gem, it will be possible to turn it into a
> non-op so that the dependency on RubyGems is removed.

Can you explain this further?  I'm glad to hear that autorequire is
going.  So what exactly will repackagers do with use_gem?

> > Does the answer to that question depend on whether I used Packager.rb in the
> > process?
>
> Package would provide (part of) the functionality implied by gem lint:
> several sanity checks could prove useful for non-RubyGems releases too.
> In this specific case, Package could scan the sources and issue a warning on
> suspect uses of require_gem (even now, an unqualified require_gem is very
> suspicious).

What's an unqualified require_gem?

> > I'm all for Packager.rb being an excellent piece of software and
> > RubyGems using it if appropriate, but I wonder if it really solves all
> > the problems.
>
> Package.rb is not a silver bullet. But it does address several problems
> exacerbated by RubyGems in a way that benefits those who choose RubyGems to
> install (and run) Ruby software and those who don't.

OK, I think I'm beginning to understand.  You're not suggesting that
RubyGems can become a repackager's dream, only that by implementing
some reasonable and non-detrimental changes, developers can be
assisted in creating repackager-friendly gems.  Is that right?

If so, I'm all for it.  But I'd still like clarification of above points.

Cheers,
Gavin