Eric Hodel
10/5/2007 11:43:00 PM
On Oct 5, 2007, at 15:10 , John Joyce wrote:
> I have a few ideas I'd like to see the Gem tool. Please correct me
> if they don't already exist!
> options, like the gem path variable, but to display, say 10 at a
> time with gem list (or an arbitrary number, or even a regex-ish
> thing...)
> Something similar to ri or other command line tools that allow for
> pagination.
> Nothing is more obnoxious than having to scroll back up a long list
> of gems.
/usr/bin/more
> Next dumb idea of mine:
> Aliases.
> Aliasing a gem name or a group of gems.
> With the ability to essentially create your own grouping of gems.
> So, say I want to create 'railsgems' as a group alias for all the
> gems I use with Rails...
> something like this:
> gem alias -g ActiveRecord RMagick ActionPack
Create a new gem with the gems you want as dependencies.
> so gem alias wold allow creation of an alias, to prevent the need
> to always type a long version number (yes I'm lazy)
> but also have a -g or --g flag for group aliasing, followed by
> argument list of gem names.
If I'm typing version numbers, I'm doing something like uninstalling
and I want to make sure I get it right. The inconvenience presented
by the extra typing helps me focus.
> With indexing, there could easily be automatic aliases for first
> character.
> so
> gem list a
> would not have to search the gems, just quickly list all of the a*
> named gems
> gem list r would list all the r* gems without searching every time.
gem help list
gem help search
> But one step further, let's also make requiring gems, particularly
> groups of gems easier.
> require 'rubygems'
> require 'my_gem_group'
>
> Or even:
> require 'rubygems:my_gem_group'
>
> or something like that!
autorequire was removed on purpose. You'll have to require the files
you want by hand.
> Granted, gem aliases might make dependencies and deployment more
> fragile in a sense, but no more than other required libraries in
> software.
More fragile is never good. I'd rather have a RubyGems that is
reliable, dependable and predictable.
> Auto generate (with optional on or off flag or gem env variable)
> RDOC that names the alias contents.
>
> I suppose internally gem aliases should essentially need to be
> either a simple alias_name_here.rb file generated that requires all
> the gems included in the alias.
You can't require a gem, you can only activate it. You can require
files in a gem, but there is no automatic way to determine what files
are appropriate (other than requiring all of them). If there is a
common set of files, it is up to the author to provide a method of
loading all of them.
> This step might make (re)distribution a little easier.
This sentence is nearly opposite of the "more fragile" one. How can
it be both more fragile and easier to redistribute?
Why do you need to redistribute? spec.add_dependency takes care of
that for you.
You have to gather the dependencies and repackage them anyways if
you're moving to a different packaging system, so I can't see how
this would decrease the amount of work you have to do.
> Perhaps an additional Rake task included to add gems in the
> requires or alias requires when those gems are not already on a
> system.
If you have your own gem listing your dependencies, `gem install`
takes care of it for you.
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars