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

On Wed, 28 Sep 2005, Sean E. Russell wrote:

> On Monday 26 September 2005 22:41, Austin Ziegler wrote:
>> The *real* harm is that without RubyGems, there would be fewer libraries
>> easily installed.
>
> This is a straw-man argument.

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.
>
> The easiest way for users to install software -- ANY software, including
> libraries -- is by using the package manager that they use for installing all
> other software on their system.

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?
>
>> You don't like RubyGems? MAKE SOMETHING YOURSELF AND PROMOTE IT.
>> Otherwise you're simply being obstructionist and *no one* has time for
>> that.
>
> Another straw man.  Users may oppose RubyGems for other reasons not having to
> do with any specific implementation of a library manager.
>
> I only fear getting locked into using a specific library manager.  I (and you)
> expect the following process to occur:
>
> 1 RubyGems is bundled with Ruby.
> 2 Gems then becomes viewed as the standard library distribution mechanism.

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.

> 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.
Much of the knowledge to be captured between the two systems is
the same, and it would make it easier for those opposed to gems for
whatever reason.  Not knowing about the internals of setup.rb I'm
not sure how feasible this would be.  And if gems ever get replaced with
something better the setup.rb distros might help with that
migration.

> 4 The perception of the standard becomes a fact, resulting in a feedback
>   loop at 3.
>
> None of this bothers me as a developer, because I won't be distributing my
> libraries as Gems.  However, it bothers me greatly as a user, because now I
> won't be able to install Ruby libraries without gems, which forces me to use
> it.  It also means that I won't be able to use Ruby at work, because of
> RubyGems' aforementioned inability to deal with firewalls properly.

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

Would your objections still stand if that were addressed?
>
>> 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.)
>
> "Carthago delenda est!"  --  The versioning mechanism must be separate from

My latin's not up to that.

> the library manager.

Why? One of the problems is that you need several versions of the
same thing installed, or you have to upgrade everything at once.
Some people have uncharitably said that GNU stands for Get New
Utilities, as a consequence of this kind of dependency problem.
With Gems, the library manager supports multiple versions, rather
than disowning the problem, which won't just go away.   Why is such
support worse?
>
> -- --- SER
>
         Hugh