It wouldn’t do RubyGems any harm If you could also take a page (or two!) out of Perl & CPAN’s book.

/I3az/

Having outlined some existing conflicts, there’s no real need for “plugins” to be within the lib folder of a gem. Why not a “plugins/hoe/my_plugin.rb” structure, for example.

FYI Ryan Davis’ summary of hoe 2’s plugins is at http://blog.zenspider.com/2009/06/hoe-2-electric-boogaloo.html

some naming convention–if your gem is named ParseTree, you require ‘parse_tree’ or what not. mime-types you are killing me!

different dependencies based on platform.

ability to have different binaries [i.e. so if I'm in 1.9 and do an install with a binary gem, it won't install a 1.8 binary].

ability to install from a url

searching for gems not be case sensitive.

Sorry they’re not related to your post just wanted to get that off my chest.
-=r

Sometimes there are valid reasons for doing this, but clearly it’s rare. When there are, it’s just one or two more files in the top level, for require (more on this later).

The pain point here for a lot of folks I think is testing and managing the load path. Under good advice, they’re told not to modify the load path, but this kind of layout can become a real pain to run libs locally or do exploratory testing work from the repo.

Gems installed that run an extconf.rb or other external builder should be made platform specific before installation. In other words, especially in ~/.gem, they should be installed as -x86* or -java* if they build on those platforms. These gems should also be explicitly interpreter version specific.

The manifest problem reaches a bit farther, however. It’s not just lib dir layout that needs a hike in order to make memory usage sane (on MRI), it’s also adding some new solution for plugin discovery. At present we’re at the crossroads, where rubygems is now running through a lot of code (on YARV) to avoid loading the gemspecs (manifests). This is great, and works well, until one starts searching for plugins. All of a sudden we’re splatting many a string all over ram, just to find a match.

It makes me almost tempted to go down the amalgamite route and to start hiding away parts of the implementation in order to avoid loading the specs. Amusingly it would have made Tims job a lot easier too, being that we could have used a simple cached nested set arrangement in a db, and just selected from it.

Just more food for thought.

If we are looking for low hanging fruit that would make lives a lot easier could we do something more with required_ruby_version to better express Ruby version compatibility from authors? Perhaps make it a requirement or use a less inclusive default like the ~> ruby version at the time of gem build?

I’d love gem list, search etc. to show me only gems expected to work on my platform but myself (like most authors?) don’t even set the gemspec property because of the (current?) > 0 default I think. This would be good first step before attempting a gem install … –test

Obviously this has come about because of Ruby 1.9 but it applies equally to people running any version of Ruby on any platform.

I don’t really see this as pushing the problem to the producer… in fact, I think it simplifies the choices of the producer, making it easier to make standard gems.

It is true that multiple gems that install into win32/process and win32/clipboard would become win32-process and win32-clipboard. However, the current situation creates potential conflicts, because no top-level name is owned by anyone. As a result, if I write a gem called win32-pid and put something in win32/process, I might stomp over the win32-process gem. Stuff like this happens in the wild.

Auxiliary files would not need to be contained in the lib directory. I was perhaps a bit imprecise. What I meant to say was that only a single directory could be added to the load path, and that directory must contain only the foo directory and foo.rb. This is already what the vast majority of gems do, since it’s a pretty reasonable practice even without enforcing.

I’ve done some work on loading multiple versions of a library. It’s quite possible for many situations, but not all, because it’s possible for loading a library to manipulate global state or run code in the global context. If gems would agree to put all running code inside a single namespace, I have code that would enable loading a gem into a different namespace (but again, this sort of thing would not work for many existing gems because of how dynamic Ruby is).

One effect would be requires will need to contain the user name for github gem distribution. Another would be gems that provide files at something other than a top-level namespace would need to be flattened. Currently I have installed win32-process, and win32-clipboard, which provide for requiring ‘win32/process’ and ‘win32/clipboard’ respectively.

In which case, if we’re going to have to change the client code require paths, we can simple make any given gem minimially “compliant” by unpacking into a directory based on its gem name and creating the stub ruby file at the top level which loads the gem within. Alternatively, if you want to avoid overriding require, just put them all in the loadpath – $:.unshift(*Dir[File.dirname(__FILE__) + '/gems/*/lib']).

Another thing to consider is auxiliary files like tests, misc data files etc. By putting them in the same foo/ directory, they would be available within the load path, which seems a bit inelegant.

I think it could be more interesting to see more work on the issue of loading multiple versions of a library, or more generally the ability to require a gem (or whatever) into its own isolated namespace (similar to python’s ability to make namespacing the job of a module consumer). I’ve done some work on this exploiting the anonymous module option of Kernel#load, to provide what is essentially, require ‘mycode’, :into => MyModule.