J
John Joyce
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.
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
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.
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.
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!
Granted, gem aliases might make dependencies and deployment more
fragile in a sense, but no more than other required libraries in
software. So, there is one last idea to go with this group alias
require approach...
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.
This step might make (re)distribution a little easier.
Perhaps an additional Rake task included to add gems in the requires
or alias requires when those gems are not already on a system.
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.
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
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.
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.
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!
Granted, gem aliases might make dependencies and deployment more
fragile in a sense, but no more than other required libraries in
software. So, there is one last idea to go with this group alias
require approach...
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.
This step might make (re)distribution a little easier.
Perhaps an additional Rake task included to add gems in the requires
or alias requires when those gems are not already on a system.