Forum: Ruby non-interactive gem install impossible?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Stephen W. (Guest)
on 2006-04-16 10:41
(Received via mailing list)
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" :)

Thanks,
Steve
Jim W. (Guest)
on 2006-04-17 02:45
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" :)

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.
Stephen W. (Guest)
on 2006-04-17 03:30
(Received via mailing list)
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
David C. (Guest)
on 2006-04-17 03:42
(Received via mailing list)
On Sunday 16 April 2006 07:27 pm, Stephen W. wrote:
>
> --Steve



Maybe you could write a shell script to do it?
Stephen W. (Guest)
on 2006-04-17 04:10
(Received via mailing list)
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
Jim W. (Guest)
on 2006-04-17 14:53
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.
Zed S. (Guest)
on 2006-04-18 22:37
(Received via mailing list)
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://www.zedshaw.com/
http://mongrel.rubyforge.org/
Tom C. (Guest)
on 2006-04-18 23:46
(Received via mailing list)
> 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
Jim W. (Guest)
on 2006-04-19 04:34
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.
Tom C. (Guest)
on 2006-04-19 04:50
(Received via mailing list)
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
This topic is locked and can not be replied to.