Chad Fowler
10/6/2004 5:19:00 PM
On Thu, 7 Oct 2004 00:42:07 +0900, Eivind Eklund <eeklund@gmail.com> wrote:
> On Wed, 6 Oct 2004 22:48:07 +0900, Chad Fowler <chadfowler@gmail.com> wrote:
> > On Tue, 5 Oct 2004 20:09:10 +0900, Eivind Eklund <eeklund@gmail.com> wrote:
> > > RubyGems are presently somewhat troublesome to repackage (due to
> > > containing too little policy to be able to fit with requirements from
> > > other systems - the problems are directory structure and require_gem),
> > > but this will hopefully be fixed in the future, as a part of RubyGems
> > > goal of being the "standard" packaging system for authors (and the
> > > only release they need to do.) For the time being, repackagers
> > > request that developers also release as .tar.gz or similar.
> > >
> >
> > I'm surprised to hear you say this. .tar.gz files contain _less_
> > policy than RubyGems. And less metadata.
>
> I was imprecise here; what I meant was a .tar.gz + standard setup.rb.
>
> And I'm surprised that you are surprised; I've been hearing grumbling
> from various packagers, not just RPA. This is one of the things that
> has been having me frustrated.
>
I'd like to hear the grumbling. Specifically, it's important to hear
of specific scenarios where something is created as a RubyGem and it
_hurt_ the ability to repackage it. As I said below, specifics are
important. "grumbling" doesn't help if we don't hear what people are
grumbling about. Even pointing out areas that might be problems isn't
nearly as valuable as pointing out a specific scenario where something
was made difficult by RubyGems.
That being said, the RubyGems developers aren't encouraging people to
only create gems. But, we _are_ encouraging everyone to make gems for
everything. With tools like Rake, it's dead easy (for most projects)
to generate .tar.gz and .gem files at the same time.
We also want to continue to hear about issues people have in making
gems--where our current system doesn't do everything it needs to for
apps and libs with specific needs. We've gotten a lot of great
feedback from the many users who have been using the system so far,
and I expect that as we see an increasing number of packages, we'll
learn that much more and make RubyGems better and better.
> > To accomodate both systems in a package-management-system-neutral way
> > will probably require additional "standard" abstractions that
> > packagers and authors can rely on just being there (included with the
> > ruby distribution, probably). The only way to really find out is to
> > create more packages.
>
> I see operating system specific packaging as extremely important, too.
> There are a lot of people that just won't use Ruby programs if they
> cannot be installed through the native operating system packages - and
> there are a lot of packaging gruops that will not accept a
> single-directory solution a la RubyGems. This may actually be most
> groups - it is at least most groups that I know about.
>
In this scenario, as I imagine for RPA eventually, it would probably
work best to auto-generate (at least the skeleton for) native packages
out of gems. People in this category won't want to use "gem install
blah", but I still believe that installation and package creation can
be made easier by starting with a gem file. RubyGems has install-time
and run-time behavior. After you've extracted a gem, you can
literally just point to it directly by changing your $: somehow and
completely forego "require_gem", etc. "gem install" could be an early
step in a semi-atomated .deb or .rpm generator, for example.
> I'm not sure if we need changes to the Ruby base or not - but
> attempting to do the package conversion tools should help us find out.
> RPA are working on exports to different packaging formats (we've got
> RPM, and are working on.deb and FreeBSD ports at the moment - or
> bitserf and Mauricio is, with feedback, help and adoptions from the
> rest of us).
>
> > I'd love to collect specific examples (on a Wiki--not ruby-talk) of
> > gem packages that do gem-specific things in such a way that it makes
> > things difficult for RPA. We can polish these rough edges away over
> > time as we move toward 1.0 of both systems. The ideal scenario is
> > that any RubyGem can be RPA-ified (pre QA) with a single script. And
> > vice versa.
>
> And converted to other packaging systems, including respecting their
> policies. I believe this is a very important goal - something that
> may be significant enough to make or break Ruby as a platform (though
> I'm not sure if it is or isn't.)
>
> If we can make this possible, it would be great - I think it could
> help raise adoption of Ruby a lot. Conversely, if we make this
> harder, we lower the adoption.
>
> This is sort of orthogonal to the use of the "native Ruby" packaging
> systems themselves.
>
Somewhat orthogonal in terms of the goal, but not very much so technically.
To summarize, I have a request: If anyone is trying to repackage
rubygems for any other system--native or not (RPA)--please keep the
feedback coming. We want to know if it was hard or even if it was
easy. Without hearing your specific stories, it's not going to get
better much faster. The rubygems-developers list on RubyForge is the
best place to send this kind of thing.
Thanks,
Chad