Re: gems is a language change, not a pkging system

On 9/26/05, Sam Roberts <[e-mail]> wrote:
> Quoting [e-mail], on Tue, Sep 27, 2005 at 10:29:17AM +0900:
>> On 9/26/05, Sam Roberts <[e-mail]> wrote:
>>> Its not a packaging system, its not an addition to the standard
>>> library, it is a change in the behaviour of one of the most
>>> fundamental of Kernel methods.
>> It is a packaging system, it is an addition to the standard library.
>> It *is also* a change in behaviour, but it is one that will behave
>> *very preditably* and without harm to those who choose -- through one
>> means or another -- to not use RubyGems.
> No harm?
>
> You, user of rubygems, state this as supposed fact.

Not supposed. Actual fact. Install with another means other than
RubyGems and RubyGems has no impact on you. NONE. Zero.

> Others, not users of rubygems, do not have this experience of "no
> harm".

Um. If they're not users of RubyGems, they're not harmed. Period. I'm
not sure how you're getting "harm" from RubyGems if you're ... not using
it.

The *real* harm is that without RubyGems, there would be fewer libraries
easily installed.

> Dismissing all code that is harmed as unncessary is missing the point.
> Depending on the language require mechanism to work as they always
> have is not wrong, changing it mid-stream is.

Please, stop with the FUD. Lots of people are successfully *using*
RubyGems -- I'd argue more than 98% of them and most of those who
*aren't* using it are either (1) not keeping up to date with RubyGems or
(2) using platforms that have screwed up Ruby installations to begin
with. Indeed, RubyGems has helped *fix* a particular problem on one of
these platforms.

>>> I fail to see the need for language support for a particular
>>> packaging system. I don't see why the need for versioned lib
>>> dependencies for rails requires a language change, I don't see why
>>> packaging requires a language change, and I don't see why versioned
>>> dependencies and packaging are so strongly coupled that you are
>>> forced to eat the language change in order to install a library.
>> Then you fail to see the point in general. Ruby needs something that
>> works similar to -- but better than -- CPAN. This means a packaging
>> system. You may not see it, but those of us who have to deal with
>> other platforms see it.
> Nowhere do I imply that ruby doesn't need a packaging system. I said
> the opposite.
>
> In particular, it needs a packaging system that is not tied to
> versioning.

Then create one. You'll have to do it quickly and you'll have to make
sure that it works *well* with platforms that aren't Linux, because at
this point, Matz *has* indicated that RubyGems is mature enough or
nearly mature enough to work toward integration into the core. I think,
though, that you'll find that more people *want* to use RubyGems in part
because it *does* support versioning.

But you know what? You don't *have* to use versioning in RubyGems,
either. It's called "gem install foo; gem cleanup". It's not quite
perfect, as I *think* it will keep around versions that are required
(lock-required) by other libraries or applications you've installed.

I'm *really* getting tired of this FUD and obstructionism. Mauricio had
a chance to establish RPA and rpa-base and dropped the ball. Package,
which seems like a pretty awesome concept, is vapour. The Debian Ruby
package maintainer who proposed porting distutils from Python was
noticeably silent about the challenge to port it himself.

You don't like RubyGems? MAKE SOMETHING YOURSELF AND PROMOTE IT.
Otherwise you're simply being obstructionist and *no one* has time for
that.

>>> They should be decoupled, require does NOT have to be changed in
>>> order to support package distribution. Split versioning into an
>>> optional facility for those who need it.
>> This is also a fundamental misunderstanding of what has to be
>> changed.
> The require change is for versioning, not packaging.
>
> If you believe that the language change is fundamental to get
> packaging "similar to -- but better than -- CPAN", feel free to point
> out why, and why such a language change wasn't required for Perl (or
> C, or ...).

Lack of imagination? You know what? I neither know nor care why such was
not done for Perl. I don't use Perl anymore. I stopped using Perl, in
part, because of "CPAN upgrade hell." C and C++ have solved this problem
in the most nonsensical way possible -- you add the major version number
to both the library name and, because you have potential API conflicts,
either namespace (C++) or prefix the function names. I like sqlite, but
libsqlite.so and libsqlite3.so are poor imitations of what RubyGems
*has* solved relatively well. Imperfectly, but miles better than *that*.

Anyone who has had to deal with the nonsense that is libstdc++ upgrades
-- or trying to support multiple versions because you've got to support
multiple incompatible versions of Linux -- will know that library and
API version numbering in the name is one of the *worst* things you can
do. I much prefer supporting AIX and HP-UX to supporting Linux because
of this nonsense. (Solaris isn't much better than Linux for this.)

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]