From: Austin Ziegler Date: 2005-10-02T03:14:02+09:00 Subject: Re: Gems is over engineered On 10/1/05, Trans wrote: > There has been a lot of talk on core about Gems and how it > interrelates to various OS (file hierarchy) philosophies. Of > significant issue is the "DATADIR problem". This is a *Ruby* problem that's accentuated by RubyGems, but is not caused by RubyGems. The integration of RubyGems into the Ruby core is an opportunity here to solve this for Ruby. > 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. > 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. > Gems used to use LIB stubs too, but that was replaced with a #require > hack. The require hack has always been there, it was just made into something that was cleaner. The stubs were a mistake because they didn't include the full package. > Now how will they fit DATA dir into this scheme? That's what they are > trying to figure out. This applies to Ruby as a whole -- remember that. Some platforms have the harder problem that configuration is separate, too. > 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. > 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. > A data dir is only relavent if the data is not subject to versioning > (which is atypical), otherwise it belongs to the lib. This probably > rubs not only Gems people wrong but Debian people a little as well. 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. [...] > 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. [...] > 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. [...] > 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. > 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: use_gem 'pdf-writer', '~> 1.1' require 'pdf/writer' This will give me versions 1.1, 1.1.1, 1.1.2, all the way thorugh 1.1.9, but *not* 1.2.0 or higher. Sorry, but appending version to the lib dir name is completely inappropriate and an utter mess. It looks stupid, too. > 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. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca