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

On 9/27/05, Sam Roberts <[e-mail]> wrote:
> Quoting [e-mail], on Tue, Sep 27, 2005 at 11:49:14AM +0900:
>> On 9/26/05, Sam Roberts <[e-mail]> wrote:
>>> Quoting [e-mail], on Tue, Sep 27, 2005 at 11:06:01AM
>>> +0900:
>>>> I think many of the rest of us consider a packaging system a
>>>> critical language feature, past due. So don't fault us for moving
>>>> forward and we won't fault you for standing still.
>> [...]
>>> Packaging is close to non-controversial, as far as I can tell. Other
>>> than wishes for improved functionality, I have heard almost no
>>> debate.
>> Um. I'm not sure where you're getting that. The entire thread -- that
>> I'll clearly admit to dominating because I'm tired of obstructionism
>> from people who aren't in the least concerned about other platforms
> Unless my memory fails me, aren't you the guy who said debian users
> using ruby should just use gems and not use anything else?

Your memory fails you. What I *said* was that Debian repackagers should
just use gems internally to the .deb. That means that the generic Debian
user won't know the difference. That also means that from the
perspective of the Debian user, there's effectively no difference.

> I'd just like to use whatever the native OS uses to install packages.
> And I'd like it to be easy for packagers to produce those packages, so
> I see more of them.

Given my experiences with native repackaging, especially on Debian,
you'll forgive me if I'm not in the least concerned about whether that
aspect is ultimately matched. However, the proposals that I've made *do*
make it easier to repackage while using the alternative #require
implementation.

> And so should you. Why should an Ubuntu user have to install apps with
> a tool other than Synaptic because its written in ruby?

Well, I don't. I work on Ruby software on my free time. I don't work on
software for Ubuntu or Debian or Fedora or Mandriva or Windows or OS X.
I work on *Ruby* software. If someone comes to me with something that is
ultimately an OS-specific problem, I have to generally punt it unless I
happen to have that OS laying around. And for most of them, I don't.

>> was about Debian folks not liking the idea of having to adapt to Yet
>> Another Packaging System. Period.
> We heard very different things in that thread. What I heard is that
> because of the way gems install, it makes them hard to package. And
> they install that way because of versioning.

Then we heard very different things, because I heard whining from
certain repackaging quarters (mostly the Debian side). I didn't hear a
single damned constructive option offered from Debian. In fact, I didn't
hear a single response to the positive proposals. Is it any wonder that
I tire of this nonsense? If you're going to be obstructionist to
something that solves a known problem (in this case, a need for a Ruby
packaging and distribution system), at least have a meaningful
counter-proposal that can be implemented in a similar period of time. If
you don't, then you're being *merely* obstructionist.

The choice to install RubyGems as one-dir-per-gem was because any other
choice requires maintenance of a database to track files that belong to
a gem -- which significantly increases complexity of the packaging
system and also suggests the use of transactional installs. Gems, on the
other hand, simply install to a directory that follows a known pattern;
the filesystem becomes the database. Uninstall becomes a simple
FileUtils.rm_rf(...). Versioning support, while deeply integrated into
RubyGems, is merely a (nearly) free consequence of keeping the gem
database implementation dead simple without requiring the construction
of a database or additional external dependencies that may not be
present or work on all systems.

> install.rb --prefix ... made packaging easy.

The two standard Ruby installers prior to RubyGems (install.rb and
setup.rb) work and work well -- no disagreement. BUT they make
uninstalling a manual process and that's iffy, at best. PLUS they offer
no solution for the DATADIR problem whatsoever. RubyGems, at least,
could use the godawful File.dirname(__FILE__) hack to make sure that the
data was kept clean.

>> Please, elaborate on these "new problems." I mean it.
> This elaboration has being going on for a week.

Wrong. A lot of whining has gone on for a week. None of the Debian stuff
seems to me to have been related to the versioning problem *per se*, but
to the distaste for the 1-gem-1-dir policy.

> If somebody has somwhere described how gems will work in the future
> avoiding these problems, I missed it in the noise of you saying they
> aren't problems.

You have missed it -- and I *have* described it, at least as far as I
see it. The technical discussion has moved, in part, to rubygems-devel
(on RubyForge), which is where it belongs.

I'm going to go out on a limb here and speak "for" the RubyGems team,
even though I'm not part of it. They're tired. Each and every one of
them has been a significant contributor to Ruby's development and
acceptance and they all have very busy day jobs. They made some
decisions regarding packaging. Some were good (single directory), some
were bad (the original .gem format, well, sucked ;), and some were
neutral but controversial (the versioning support, because of known and
perceived problems with the various language packaging mechanisms in the
past, usually some variant of 'dll hell'). They, by and large, wrote a
*RUBY* system without any particular concern for repackaging. This, of
course, pissed off the Gods of Debian.

Right now, they're watching people who have pretty much sat on the side
of the whole process, if they've even been involved at all, savaging
their work -- their labour of love -- because it doesn't meet their idea
of intellectual or packaging purity. *NOT* because it causes real
problems, but because it makes things harder for repackagers. As I said,
in the year or so that I've been providing gems, I haven't seen any
users with problems that were *caused* by RubyGems -- aside from the
occasional bug, of course ... which happens with any software. These
bugs, by the by, haven't all been caused by the RubyGems team -- some
have been in the dependencies.

These people aren't offering anything constructive. Seriously, is "port
distutils from Python" a *constructive* suggestion, when we already have
a system that works -- and has garnered praise from people whose first
experience with Ruby has, in fact, been RubyGems to install Rails?

I've taken it upon myself to be the lightning rod here. I have no
problem, as someone who has to support *packaged* software on a lot of
different platforms, busting the notions presented or even being
apathetic to the particular concerns. Ultimately, I'm not apathetic --
as the 15-point Ruby/RubyGems change proposals that I've made suggest
that. I'm also in discussion with one of the RubyGems contributors
trying to solidify the #require rules for RubyGems in the core.

What I really don't care about is whether I tick off these people who
are basically acting like the peanut gallery and not really adding
anything constructive. I think, honestly, that despite the effort that
the RubyGems team has put into RubyGems, they would give way if
something demonstrably better made its way into Ruby's core.

But there's nothing there. And whether or not it's RubyGems that's put
into the core, the DATADIR issue has to be solved -- because the current
situation is just a mess. That mess is also going to cause pain for all
Ruby developers until they adapt to it. RubyGems, at least, makes it
easier for the data to be self-contained until it *is* fixed.

On 9/27/05, ES <[e-mail]> wrote:
> James Edward Gray II wrote:
>> On Sep 26, 2005, at 8:54 PM, Sam Roberts wrote:
>>> Depending on the language require mechanism to work as they always
>>> have is not wrong, changing it mid-stream is.
>> Luckily, you can stop Ruby from ever evolving on your box again,
>> today.
>>
>> Bless Ruby 1.8.3 as the final version of Ruby, as far as you're
>> concerned, and you have implemented iron-clad protection for the
>> current require behavior than none of us can rob you of.  This is
>> probably a really good move for you too, since I suspect the Ruby 2.0
>> specification must be very alarming to you.
>>
>> I think many of the rest of us consider a packaging system a critical
>> language feature, past due.  So don't fault us for moving forward and
>> we won't fault you for standing still.
> Then why is the current discussion mostly about a half-assed standard
> library addition rather than a language feature?

1. RubyGems isn't half-assed. Certain parts of the implementation may
   seem half-assed because of the limitations of adding this sort of
   thing in Ruby to cover a core C feature (e.g., RubyGems is currently
   only invoked by #require on a LoadError).

2. Most of the current discussion has been based on misconceptions by
   people about what RubyGems currently does or will require them to do.
   Most of it has also been based on the current implementation *which
   will change* (must change!) before integration into the core of Ruby.

> Make Gems the *only* way to #require anything or leave it out.

Except that all we're talking about is dynamic resolution of installed
packages. That's the *real* change that RubyGems brings, and it's
completely invisible to most users. Packages not available as gems are
able to be installed the same way as they are now.

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