Re: RubyGems TODO

On 9/21/05, Austin Ziegler <[e-mail]> wrote:
> Okay. I said in the main thread on ruby-core that I'm putting together a
> proposal for this. Here's the set of proposals. I would happily assist
> in the development of any of these, but I am completely swamped until
> after RubyConf. None of the problems are conceptually difficult and I
> believe that the model that we should encourage is that package
> maintainers should trust RubyGems to do its job properly, because it
> does its job a *lot* better than CPAN does (IMO). To be clear, I *do
> not* think that we should encourage the manual unpacking and
> installation of gems and that if repackagers do that, they're doing
> something that is contraindicated and they're hanging their users out to
> dry.
>
> This list, obviously, is my opinion. None of this eliminates other
> possible improvements already on this thread.
>
> 1. require_gem needs to go away. We still need a way of saying that gem
>    foo-1.3.5 represents foo/bar version 1.3.5, but I believe that this
>    can be done with modifications to Kernel#require to accept a version
>    parameter. The drawback, of course, is that this means that the
>    require code has to be smarter. Eliminating require_gem will also
>    eliminate the auto_require feature, something I think I'm going to
>    get rid of from my own gems moving forward in any case.

Not a bad idea. We might need some strict naming conventions then...
which I am mostly against. Sometimes there is a reason to deviate.

> 2. If require_gem is eliminated and replaced with activation (per
>    earlier discussions, also #4 on Chad's -core list), then we can even
>    get RPA-like "stable release suite" concepts, so that you can have a
>    metagem (no different than a real gem) such that you might do:
>
>      require 'gemreview/rails', '1.0.0'
>
>    This could activate a series of gems related to Rails produced by the
>    "gemreview" team. Activation would be the equivalent of locking a
>    gem's path into $LOAD_PATH.
>
>    The search order should be:
>
>      manually activated gems
>      site_ruby
>      installed gems
>      ruby-lib

I have some ideas on how to hit a few of these at once (see bellow).
As far as search order goes, I completely agree. I do think that it
would be nice to query a specific location or at least provide a gem
API so code can be configured to select more specifically.

> 3. Eliminate case-sensitivity. Having a Usage gem or a RedCloth gem is
>    confusing. At the same time, I will also acknowledge that there's a
>    mismatch between gem names (e.g., pdf-writer, color-tools) and what
>    they provide (e.g., pdf/writer and color). There's got to be a better
>    way to handle gem naming issues and mapping issues. This is, IMO,
>    vital to #2.

I strongly disagree on this point. It is common for many filesystems
to have case-insensitivity and the other way around. I think the
solution is to encourage a specific naming scheme that is only a
recommendation not a rule. This follows along with how people tend to
code in ruby a certain way. Some deviate but it is still not that bad.

There are people who are annoyed by small things like this but it
comes down to the authors decision. However, there is a feature that
could remedy some of this pain: why not support intelligent aliases?
One could alias a specific gem to a new name that may or may not
specify a version. The cool effect is being able to configure a little
more agilely. Imagine two packages that use the same compatible API.
Now if I wanted to switch which one I used what would I use. Right now
a switch in code or some config file would have to be used. If gems
supported an alias system we could solve a lot of these issues.

On your meta-gem idea, it is well founded and a good start. I would
propose that we have a way of packaging a _setup_ or _gem environment_
rather than construct meta-gems. This way we could have a setup that
is fed from an RPA type process w/o much trouble.

The next step for that kind of feature would be to support combining
and moving these _setups_ in and out easily in one command. I think
this is getting to the _complex_ stage but it would be really nice
(especially for developers who want to do tests in multiple setups).

> 6. Post-installation message capabilities. Let me give the user a
>    message to see after they've installed the gem.

This is a good thought. I would like to see something like this,
_however_ rdocs do get us most of the way there. Everyone, you are
using rdoc right???? Making the documentation more accessible might be
a good idea. gem_server works but a good CLI tool might be in order.

> 7. It might be useful to have a LICENCE field so that users could
>    possibly develop installation policies (for those zealots who won't
>    install anything that isn't GNU GPLed).

And to also inform the user. I think most packages have their license
it their documentation and source code but this would make it more
obvious. It also makes things more clear when you might want to
package something up, what licenses are included in the package (like
_setup_ above) so you can include an informative list with the
package.

> 8. This is also not completely Gem related, but it would be nice, for
>    extensions, to be able to detect where one's development environment
>    might be on Windows.

It would be nice if there was a user script setting for certain
actions so this kind of setup could be automated. One could then say:
when you install, please pass here first. This might also be a good
one for people complaining about gems not playing nice.

> 9. External (e.g., non-Ruby) dependencies references would be useful.
>    I'm thinking something like:
>
>      spec.external_dependencies = { 'ImageMagick' => 'http://....' }

Yes. I agree that there needs to be a way a user can find what he
needs w/o trying to install first. The script could then setup the
environment, throw exceptions (for custom failures), and other things
I haven't thought of yet.

> 10. "Optional" dependencies. That is, things that aren't *required* to
>     make the gem work, but can add additional functionality. This would
>     apply to both gem dependencies (as Text::Format can use
>     Text::Hyphen, but doesn't require it for basic operation) and
>     external dependencies.

Yes. Again, this one should be very high priority IMHO.

> 11. Architecture-dependent and architecture-independent directories.
>     This is potentially a big shift in the way things work, as it goes
>     out of the dir-per-gem-version style. Sort of. The current
>     installation is something like:
>
>       /usr/local/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo.rb
>       /usr/local/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo/bar.so
>
>     (This is approximate, nothing more. I don't have any compiled gems
>     handy to verify). There's no reason that can't be changed to:
>
>       /usr/share/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo.rb
>       /usr/local/lib/ruby/i386-linux/gems/1.8/gems/lib/foo/bar.so
>
>     or something like that. Up front, I don't really care HOW it's done.
>     Since it will be in a predictable prefix location with a predictable
>     path pattern, it shouldn't be significantly harder to remove on
>     uninstall than the current dir-per-gem-version mechanism. In this
>     way, RubyGems can help those who give a damn about FHS or LSB the
>     tools they need to make things work while not forcing the rest of us
>     who don't care to adapt to their particular neurosis.
>
>     This would ideally require a "gem rebuild" command or something to
>     force the arch-dependent stuff to be rebuilt.

This wouldn't be bad, thought I can't imagine what it solves that a
good query interface couldn't. It seems more aesthetic.

> 12. Add the Rake support patch. (There's a patch available to allow
>     Rake-driven extension builds.)
>
> Incomplete, but I think it's thorough and covers the current discussion.

Good plan. I've fallen in love with Rake.

Brian.