From: Austin Ziegler Date: 2005-10-02T08:09:56+09:00 Subject: Re: Gems is over engineered On 10/1/05, Trans wrote: > Austin Ziegler wrote: >>> Gems doesn't support a DATA dir at the moment. Of course they are >>> working on it and fitting it into the Gems "philosophy" --which is >>> that everything is stored in gems and the outside looks there for >>> its needs. >> This isn't quite correct. > How so? Gems even caches data to the gems lib directory. This is a side effect of the problem not being solved under Ruby, not a solution of Gems. That people are able to *easily* and *consistently* be able to get at data from a gem and be assured that the data is appropriate for the version of the gem. This is, however, one of the things that repackagers hate *most*. >>> For example, a BIN file actually is a kind of stub that requires a >>> file from its gem. >> This is a stub, but it's a versioning stub. That is, the stub is >> aware of versions installed and as such you only have to have a >> single stub installed to be able to run multiple versions of a >> program offered by Gems. > Ah, the _1.0_ version parameter (I couldn't find any documentation on > this btw). I suppose that's no worse or better then symlinks. Still > its a rather trival thing for the end programmer to do If they want. > What troubles me is that a manual install with setup.rb is gogin to be > different the a gems install --probably not a big deal in this case > (though I imagine thjere are edgecases, $0 comes to mind), but it does > illustrate how Gems alters things. That doesn't bother me at all. If you install with gems, you get additional features. If you don't, you don't. >>> One of the problems with this, besides that it really irks other >>> distribution managers b/c it poopoos on their philosophies, is that >>> it adds Gems' versioning to all of it. So now you have not only >>> versioned libs, but bins and data too. >> This is actually valid. If you read my statement to Jim Weirich on >> ruby-core, you would have noted that at least for Ruwiki and >> PDF::Writer, I *require* versioned data, not just version-independent >> data. However, the bin versioning isn't the case as I outlined above. > The put the data with the lib. Why should it not be there if it is > versioning along with the lib. Why are .rb files special? What makes my > data and program different. lispers would tell you otherwise. The data > could just as well be encodded in Ruby. So what's the justification of > putting it elsewhere? As I said above, it is the fact that the data is *with* the lib that drives the repackagers nuts. I don't have as big an issue with it -- I use that right now. >>> So I've been thinking about this and I've come to the conclusion >>> that all versioning belongs to the LIB only! >> This is incorrect, as noted above. Versioning can be applied to >> either data or libs. > Sure, but my point is then why separate them? Hrm. Because FreeBSD and Debian and ... various other platforms demand that they be separated or they're not right. >> Um. I suspect that data versioning -- and remember we're talking >> about "central" data, here, not user data -- is more important than >> you think. If I change data formats and want people to be able to >> have both v2 and v3 of my lib, they need to have *both* datafiles >> present, even if they're named the same. > Right. I'm not saying any different. Okay. But this is part of the reason why a solution is needed -- and it's a *Ruby* problem. >>> Consider the bin dir. Gems' use of wrapping the exe is clever but is >>> rather useless with regards to versioning. How are you going to tell >>> the exe to use a different version? ... So it's up to the designer >>> of the exe to add that if he really wants it, manually writing a >>> stub is easy enough, or somehthing that has a "--ver" option. Gems >>> can't really help. >> Actually ... gems *does* handle it properly. Read the stubs that are >> in your bin dir. > You are right, I miss spoke here. The "_1.0_" paramter allows it, I > hadn't seen anything written up about this. It's a bit of an ugly > hack, but it does the job. Nonetheless, my point here is really that > can be trival for an end programmer to implement and then they have > greater control over it themselves. Hmm. I *would* like to be be able to specify a stub that gets installed rather than the default, but I think that the existing stub is sufficient for most peoples' purposes. >>> As for the data dir, what does it really matter is if the data is in >>> with the lib or outside? >> This is where the Debian (and FreeBSD and ...) folks would disagree >> with you, and I would by and large be inclined to agree. I'm told >> that Ruby Gnome support is a particular mess for this. > Ha! Ha! That's funny. You're argeesing with them now? Well, I don't > see why. I was agreeing with you! I agree with them that there needs to be an API to get at the data cleanly. Simply doing data relative to File.dirname(__FILE__) is ... fragile. I disagree with them on other points. >>> In conclusion I think Gems is over-engineered. Tightly tying a >>> versioning distribution manager to Ruby's library require mechanics >>> is too much. And b/c of this will ultimately be bad for Ruby. >> This is not a logical conclusion from your arguments, and it's >> certainly not logical from the misinformation involved with your >> arguments. I believe that it is precisely that versioning that makes >> RubyGems *desirable* because there's nothing else even remotely >> suitable, and API versioning is something that the *language* needs >> to deal with, not the operating system. > Sure it does, though admittedly I didn't fill in all the little steps > along the way. An what misinforamation, I had ONE fact wrong. > They rest are essentially opinion --which can't be misinformation. I'm > not arguing against versioning, just the particular approach. And I > agree, with you last stament here. But I might go further and say that > the language shouldn't limit versioning to a package distribution > system. If I want to do versioning but not use Gems how is Ruby going > to help me? Make Gems integral to Ruby and Gems becomes the only way. > VERSIONING SHOULD NOT BE TIED A PACKAGE DITRIBUTION MANGER. Um. Sorry, but do you actually have a solution that works, then? One that *doesn't* tie versioning to package management? The idea of *not* having the two pieces together is a bit silly, at that, as package management is centrally about versioning, and API version management is lacking in every language that *I* know (and that's quite a few). This really does offer Ruby an opportunity to tie things together that work well. >>> I believe a better solution may simply be to extend require to >>> provide optional parameters, among them special version constraints >>> and then Ruby can look for libs following a simple convention of >>> appending version to the lib dir name. >> I've already argued that "require 'foo-1.0'" is inappropriate (as >> well as Ugly). This means that I am *always* fixed to a particular >> version number in an application, rather than possibly getting a >> compatible sub-version, as with RubyGems possible future capability: > You know what, the "ugly" arguments doen't fly here. I don't think its > ugly. I think it looks fine. And you're later starement is simply not > true. You're thinking inside the box. The require statment can be > adjusted to do the version lookup. By your reasoning Gems itself > wouldn't work. Oh, bollocks. The "ugly" argument flies quite well, especially when we're talking about a language that we both consider quite beautiful, although apparently for different reasons. You can accuse me of thinking inside of the box, but the reality is that both of these problems are interrelated -- and RubyGems is suited perfectly for the combined problem. >>> So all versioned material goes in the lib, the rest remains version >>> free. It's a simple convetion, although not ideal in some minor >>> respects, it's simple and effective. >> It's not ideal in major respects. It's also neither simple nor >> effective for the reasons noted above. > What reasons? You haven't given any facts or rational explination of > your opinions except a single incorrect one. "stupid" and "ugly" are > not helpful. "Incorrect." Sorry, it's not incorrect -- if I have to do: require 'foo-1.0' I have tied myself irrevocably to version 1.0. If I can do require 'foo' Then I'll get whatever the latest version is installed. If I can do: require 'foo', '~> 1.1' Then I'll get the various versions as indicated. This is *best* handled by something that doesn't actually have to scan *directories* to see if there's an appropriate version, but can scan a quick database of installed packages ... just like RubyGems does. Package managers *always* have to do version management. The only difference between RubyGems and other package managers is that Chad, Jim, and the others who designed it also decided to handle API versioning *at the same time*, since the API version and the package version are often closely related. Again, if you can point me to a solution that is *easy* and *not ugly*, I'll evaluate it and, if appropriate, champion it. RubyGems solves two major problems for Ruby, and I think it solves it elegantly. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca