Gem ideas

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.

On Oct 5, 2007, at 15:10 , John J. 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.

On 10/5/07, Eric H. [email protected] wrote:

of gems.

/usr/bin/more

more or less


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Oct 5, 2007, at 17:52 , Rick DeNatale wrote:

On 10/5/07, Eric H. [email protected] wrote:

/usr/bin/more

more or less

$ ll /usr/bin/more /usr/bin/less
-rwxr-xr-x 2 root wheel 118508 Mar 20 2005 /usr/bin/less*
-rwxr-xr-x 2 root wheel 118508 Mar 20 2005 /usr/bin/more*

less is more

(you can shoot me now)

Quoth Eric H.:

less is more

(you can shoot me now)


Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. – Syndicate Wars

Or is it?

$ ls -l /usr/bin/less /bin/more /usr/bin/more
ls: cannot access /usr/bin/more: No such file or directory
-rwxr-xr-x 1 root root 32176 2007-08-08 08:05 /bin/more*
-rwxr-xr-x 1 root root 129984 2007-02-20 01:04 /usr/bin/less*

Regards,

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs