From: Austin Ziegler Date: 2005-09-27T20:40:53+09:00 Subject: Re: gems is a language change, not a pkging system On 9/27/05, Sam Roberts wrote: > Quoting halostatue@gmail.com, on Tue, Sep 27, 2005 at 11:49:14AM +0900: >> On 9/26/05, Sam Roberts wrote: >>> Quoting james@grayproductions.net, 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 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 * halostatue@gmail.com * Alternate: austin@halostatue.ca