--nextPart1258626.pc9opKdtUh
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 28 September 2005 08:54, Hugh Sasse wrote:
> I beg to differ: gems do make installation easy, and provide useful
> supporting infrastructure for testing and documentation, which means
> not only do you get a simple install, but good practices are
> encouraged.  This cultural stuff is useful.  And I think the
> simplicity of installing Rails has contributed to its success, for
> one thing.

That's the funniest thing, because my current objections to Gems are based=
=20
largely on multiple bad experiences trying to install Rails through RubyGem=
s.

> But RubGems doesn't prevent this.  If you get a gem and can unpack
> it, and then you can repackage it using whichever packaging system
> fits your setup, then what is the problem?  Specifically: what can
> gems do to make [re]packaging easier?

Mauricio Fern=E1ndez and Eivind Eklund have covered this quite well, I thin=
k.  I=20
don't do a lot of repackaging, so I can't contribute anything beyond what=20
they've already said.

A long time ago, before REXML was added to Ruby's CVS, I tried building a G=
em=20
for REXML, and the experience was an utter failure.  I admit that this=20
colored my perception of RubyGems, because even back then people were pushi=
ng=20
me to distribute REXML as a Gem.  I echoed Austin's attitude toward Debian=
=20
packagers. =20

Much more recently, I wanted to evaluate Rails for replacing some=20
infrastructure on a project at work.  That, too, was a waste of time becaus=
e=20
of the NTLM firewall issue.  I think I did eventually get Rails installed,=
=20
but it would have been much easier and I would have used less time if I cou=
ld=20
have pulled a tar.gz and run setup.rb.

I haven't tried packaging recently; if RubyGems solves the firewall problem=
,=20
then I may re-evaluate Gems for some of my other projects.

> > I only fear getting locked into using a specific library manager.  I (a=
nd
> > you) expect the following process to occur:
=2E..
> Yes, but that doesn't actually mean to the exclusion of other forms.
> There will be people making RPMs or whatever.  What can we do to
> facilitate that?  Ruby culture has not been, in my experience, about
> the one correct way to do things.

I greatly appreciate that sentiment.  I suspect that addressing Mauricio an=
d=20
Elvind's issues would solve the problem.  Somebody else mentioned that bein=
g=20
able to pass gem a command that would cause it to list its dependencies wou=
ld=20
be a big help.  I don't know; perhaps gem already has this.

I still have questions about gem's operation.  For example, if gem X depend=
s=20
on Y, and I've already installed Y but not as a gem, will RubyGems see that=
? =20
If not, then repackagers can't use the pseudo-solution that's been proposed=
=20
of just wrapping the gem command.

> > 3 Library developers, especially newcomers who've never used setup.rb,
> >  will only distribute their packages as Gems.
>
> This is the crux, really, isn't it?  I think RubyGems should
> facilitate the correct construction of setup.rb based distribution.

That would be ideal.

> The firewalls issue needs to be addressed, definitely.
> What's the nature of the problem?

I don't know.  That it doesn't work?  Honestly, I've spent very little time=
=20
investigating it.  As I've said, my interest in RubyGems has only gotten=20
smaller with every interaction I've had with it.  By the time I got to the=
=20
firewall problem, I had neither time nor interest in debugging it.  On top =
of=20
that, I'm not sure I could justify spending time on it while I was at work,=
=20
where I see the problem.

> Would your objections still stand if that were addressed?

The firewall issue is *my* main issue, and I'd be less hostile towards=20
RubyGems if it were addressed.  If the issues around repackaging were dealt=
=20
with, then I'd probably feel OK about the system.  I'd have to have a bette=
r=20
experience with packaging my own gem before I could become an advocate.

None of this will address the fact that I still firmly believe that the=20
versioning system should be external to RubyGems.  I don't believe that it=
=20
must, or should, be so tightly integrated.  For one thing, it means that co=
re=20
libraries will never be versioned, and there's no reason why they shouldn't=
=20
be.  It is still much easier to fix bugs by upgrading a single library than=
=20
upgrading an entire Ruby version -- for one thing, it allows core library=20
developers to push fixes more often than Matz offers new releases of Ruby.

> > "Carthago delenda est!"  --  The versioning mechanism must be separate
> > from
>
> My latin's not up to that.
=2E..
> than disowning the problem, which won't just go away.   Why is such
> support worse?

"Carthage must be destroyed."  There was a Roman senator named Marcus Porci=
us=20
Cato who would end every speech with "Ceterum censeo Carthaginem esse=20
delendam", which means "And so, I conclude that Carthage must be destroyed.=
" =20
It didn't really matter what he was talking about... he said it endlessly,=
=20
interjecting it into every conversation.

I was alluding to the fact that I feel the same way about the versioning=20
issue.  I believe library versioning should be independant of RubyGems, and=
=20
that RubyGems should be dependant on the versioning.   Right now, they're=20
co-dependent, making versioning useless to anybody not using RubyGems.  It =
is=20
in this way that the support is worse.

Or, rather, it isn't that RubyGems *uses* library versioning.  Gems advocat=
es=20
continually misunderstand this, which means I'm not communicating it clearl=
y=20
enough.  I think it is *great* that RubyGems uses library versioning.  I=20
think versioning is so greate that *every* package should use versioning. =
=20
Unfortunately, versioning is tied so tightly to RubyGems that it *can't* be=
=20
used outside of RubyGems.

=2D-=20
=2D-- SER

"As democracy is perfected, the office of president represents,=20
more and more closely, the inner soul of the people.  On some=20
great and glorious day the plain folks of the land will reach=20
their heart's desire at last and the White House will be adorned=20
by a downright moron."        -  H.L. Mencken (1880 - 1956)

--nextPart1258626.pc9opKdtUh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux)

iD8DBQBDSmBVP0KxygnleI8RAtxGAKCmgGBVWRiTw7IC5hHkf0V7J4IDCwCfYtxG
8NX1++Ki3Xlsinu1+1BfkRM=
=oF7R
-----END PGP SIGNATURE-----

--nextPart1258626.pc9opKdtUh--