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". 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. For example, a BIN file actually is
a kind of stub that requires a file from its gem. Gems used to use LIB
stubs too, but that was replaced with a #require hack. Now how will
they fit DATA dir into this scheme? That's what they are trying to
figure out.

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.

So I've been thinking about this and I've come to the conclusion that
all versioning belongs to the LIB only! 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.

But think about it.

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. Debian deals with the same issue by using symlinks. ruby ->
ruby1.8 for example.  Its' a nicer solution. But Gems can't use that
b/c it needs to be cross-platform and Windows does't have symlinks. So
were back to convention.

As for the data dir, what does it really matter is if the data is in
with the lib or outside? It really only needs to be outside if it is in
some way "shareable" and if that is the case versioning is bad indeed
since mutliple resources will call on it --which app has rightful
control? So at that point the data itself starts to become it's own
poject and probably should get an API.

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.

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

T.