Non-interactive gem install impossible?

Ruby
1

As you know, “gem install mongrel -y” presents this:

Select which gem to install for your platform (i686-linux)

  1. mongrel 0.3.12.4 (ruby)
  2. mongrel 0.3.12.4 (mswin32)
  3. mongrel 0.3.12.3 (mswin32)
  4. mongrel 0.3.12.3 (ruby)
    …

Is there any way to reliably do this non-interactively?

echo “1” | gem install mongrel -y

does not work, because the proper choice may be 1 or 2 for (ruby) - it’s
inconsistent between versions and various gems.

Please don’t say, “use expect” :slight_smile:

Thanks,
Steve

2

Stephen W. wrote:

As you know, “gem install mongrel -y” presents this:

Select which gem to install for your platform (i686-linux)

  1. mongrel 0.3.12.4 (ruby)
  2. mongrel 0.3.12.4 (mswin32)
  3. mongrel 0.3.12.3 (mswin32)
  4. mongrel 0.3.12.3 (ruby)
    …

Is there any way to reliably do this non-interactively?

echo “1” | gem install mongrel -y

does not work, because the proper choice may be 1 or 2 for (ruby) - it’s
inconsistent between versions and various gems.

Please don’t say, “use expect” :slight_smile:

Future versions of gems (probably in the 0.10.x series) will be smarter
about selecting the gem to install. It will figure out the “best”
platform (but allow you to specify something other than the default if
you desire).

–
– Jim W.

3

Jim W. wrote:

Future versions of gems (probably in the 0.10.x series) will be smarter
about selecting the gem to install. It will figure out the “best”
platform (but allow you to specify something other than the default if
you desire).

Thanks Jim.

Is this something that’s already in development? Or something that
still needs to happen?

–Steve

4

On Sunday 16 April 2006 07:27 pm, Stephen W. wrote:

–Steve

Maybe you could write a shell script to do it?

5

David C. wrote:

Maybe you could write a shell script to do it?

I’d rather fix gem. But, I’ll take a significant hit coming up to speed
on gem, and certainly wouldn’t attempt it if it’s already underway or
just around the corner.

–Steve

6

Stephen W. wrote:

Is this something that’s already in development? Or something that
still needs to happen?

Its part of the refactoring that will make local and remote gem installs
more consistent. Part of that refactoring will address making better
use of the platform information. Some of the code has been done, but
its still mainly in the planning stage at this time.

–
– Jim W.

7

No idea really. I also would like to know how I can clear out older
gems
from the mirrors so that people don’t get 200 versions of mongrel to
choose
from.

Zed A. Shaw

http://mongrel.rubyforge.org/

8

No idea really. I also would like to know how I can clear
out older gems from the mirrors so that people don’t get 200
versions of mongrel to choose from.

Hm. Right now the gem index builder uses all the gems that it can
find… perhaps it should check to see if they are set to “active” in
the RubyForge file user interface before adding them to the index?

Yours,

Tom

9

Tom C. wrote:

No idea really. I also would like to know how I can clear
out older gems from the mirrors so that people don’t get 200
versions of mongrel to choose from.

Hm. Right now the gem index builder uses all the gems that it can
find… perhaps it should check to see if they are set to “active” in
the RubyForge file user interface before adding them to the index?

Hmmm … I’m thinking that the gem index builder probably doesn’t want
to be too tied to the RubyForge structure, as it it used to build gem
indexes on a number of other sites.

But it would be a simple thing to copy old gems into a archive
directory. Then the gem indexer won’t see them and the index will not
contain them. It should be “simple” (for some definition of simple) to
sweep the current gems and select gems to be moved. I would suggest
leaving at least 3 versions and anything in the last year in normal
directory, everything else moves to the archive.

If you want to have the gems in the archive available for folks that
really want the old versions, then run the gem index builder in the
archive directory as well (and the index there will be independent of
the main index). If you want an archived gem, just use the --source
option on the gem command to grab it from the archive.

Shouldn’t be too hard to setup.

–
– Jim W.

10

On Wed, 2006-04-19 at 09:34 +0900, Jim W. wrote:

to be too tied to the RubyForge structure, as it it used to build gem
indexes on a number of other sites.

Oh, definitely, I agree. I should have said, perhaps the script that
copies over the gems into the directory that the indexer sees should
first check to see if those gems are marked as active. So, wouldn’t be
any change to the indexer code.

the main index). If you want an archived gem, just use the --source
option on the gem command to grab it from the archive.

Shouldn’t be too hard to setup.

Yup, and also, there’s always the old-fashioned way - just download them
from the project’s file area and install them --local.

Yours,

Tom