From: Aredridel <aredridel@...>
Date: 2004-11-18T02:44:18+09:00
Subject: Re: [ANN] rpa-base 0.2.3

> Can I put in a plea for not cultivating the "program2" syndrome in
> Ruby programs and libraries?  Maybe it's just a pet peeve... but I
> really hate it when, a year or two after setting up a system with kde,
> xchat, apache, libxml, etc., I'm suddenly running kde3, xchat2,
> apache2, libxml2, etc.  Those are silly names for programs, whereas
> the original names were relatively reasonable.

I agree that it's among the most ugly things ever, having to mix up
the name with the number.

The biggest problem comes from the fact that selecting a library
essentially needs a primary key of (name, version); the filesystem
doesn't have separate fields, so every language or system solves the
versioning selection problem differently.

There's the contextual selector (gems), where you supply metadata and
it picks the right one. Heaven help you if you need both.

There's the explicit versioning model, like libxml2, which ugly, never
has name-space collisions, at the expense of having to apply the
version number by hand. It's a very IETF-style solution: guaranteed to
work as long as everyone follows best practice, and lets you blame the
ones that don't. Ugly, too, just like a lot of IETF protocols.

Then there's the head-in-the-sand method, where you ignore it and hope
you never have conflicts. It only works for small projects.

And then there's the Raymond Chen Microsoft camp, where you just bend
yourself into pieces to not break anything. Who cares if the project
is ten times more complex? At least it won't break the old usage.

> The prospect of everything having to end in a number as a packaging
> workaround suggests to me that something needs to be addressed in the
> packaging system.  Surely having a package/program/library name and a
> version number as separate things is not only more aesthetically
> appealing but vastly more scaleable.

Handling it in the packaging system at some point moves it back to the
filesystem, at huge code complexity expense. If you "require_versioned
'foo', 2", then at some point, there has to be code that turns that
into /rubylibdir/foo-2 or something similar to load the files? Why not
skip that and save a few characters and just have "require foo2"?

I happen to think that "foo2" looks really ugly, because people run it
together and can't tell what's the family name and what's the specific
instance version, and developers start munging it and your mailing
list starts looking like "install foo" "which foo?" "2.0" "Oh, you
mean foo2! I thought that was something else."  My simple suggestion
to fix that is to put a dash in the name. "require 'foo-2'" neither
offends my sensibilities, nor does it require any maintenance by
anyone other than the package author.

If the internal namespaces follow similar conventions, you even have
the problem of diamond dependencies solved:

   app requires framework which needs lib version 1; app requires
framework which needs lib version 2.

It's not common (yet, thankfully), but if everyone puts the major API
version in the library name and namespace modules, then it's a non
problem. It's ugly, but it will never break. If there's no namespace
management, then ugly collisions occur, and you get answers like "No,
you can't use foo with bar, because they need different versions of
baz"

> David (who intends to keep calling Ruby Ruby, whatever its version :-)

Ari, who intends to do the same, but be specific when it matters.

P.S. I hated libfoo2, as well. .. until I had to fix something that
was busted because of versioning issues. Now I can't reccomend it
strongly enough.