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

> 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.

Labours of love are no excuse for forcing an idea that does not work for
others
upon them. There is a question as to whether this belongs in the standard
library as it does not. And the Labour of Love will be appreciated and used
by,
well those who appreciate and use it. (As well you appreciate in your
expressed
frustration, and apparent dislike of Debian). That said I much appreciate
the
contributions of various people including members of the Gems team to Ruby.

How many balls of string do you need to reach the moon, ... indeed it is a
big one:

Gems must not make it MORE difficult for repackagers. What on earth would be
the point of that. Ruby programs/libraries should not be a second class
software on ANY OS. Nothing should be done that in any way makes this more
likely. (How many programming languages are there, if they all had
idesyncracies which created difficulties (for those who offer seamless
larger
systems) what kind of a mess would there be, and why should Ruby choose to
turn
itself into a language that is regarded in this light.)

Work that out, then offer us Gems "in ruby head"

Whatever you come up with must play WELL with existing packaging systems.

As I understand it Mauricio has made his issues with Gems known at
all stages of development, and continues to do so; and he has in the past
contributed a fairly high percentage of code to it. Some of us have been
content until now to sit by and watch him labour in our interests.

I do use Debian, I even now package with/for Debian. I find myself drawn
increasingly to it, perhaps because my experience with Debian has been very
different from the one you continually describe, perhaps i took the time to
understand the tool a bit better, 15,000 packages available to choose from +
and very few issues, updated/upgraded daily. It's a bloody astounding
achievement, AND it is not some little package management system, it is used
by
almost as many Linux distributions as Red Hat, AND it could in future work
just
as well with say FreeBSD, ... though i for one am very happy with Linux.

Having said this, i do not think the problem is in any way confined to
Debian
repackagers, or Linux alone at that.

A last point on repackaging, If i am an inexperienced user of an OS, I
probably
do not want your Joe Random, software installed directly on my system unless
I
have had a group i trust review it (whether a company or other), approve it,
and assure me it will play well with my system.

It is unlikely i will engage further in this debate, but i am sick of seeing
this shoved as some wonderful solution, and a done deal, if it fails as
obviously as you and others state it does, in what should be one of its more
obvious and primary objectives (in addition to whatever else it might do for
you). Let us see something we like and can agree with first, certainly don't
let us obligate ourselves to having worse, unless perhaps, an alternative
that works
for the rest of us can be introduced into the Standard Library/Core whatever
once that has been prepared. Indeed as it probably would be, if those
politely
'sitting on the side' and trying to persuade developers of their needs, had
gone ahead and produced an alternative system that worked better and could
be
proposed instead.

I don't care what you do with gems, provided they play well with other
systems,
and certainly don't make it in any way harder for (re)packaging of libraries
that use
them. Indeed I may come to use and appreciate them, for now, wait with this,
work
on them, show us how they improve things. Gems are already out there.

This thread goes on because people are not sitting idly by. People generally
happy
remain silent and watch the course taken by Ruby are jumping in.

(and hands off Debian it is WAY WAY Better than Windows :-)

Ralph

On 9/27/05, Austin Ziegler <[e-mail]> wrote:
>
> 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]
>
>


--
email: [e-mail]
.: [e-mail]
SiSU: http://www.jus.uio.no/sisu