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
Stephen Waits 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 Weirich
--
Posted via http://www.ruby-forum.com/\.
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/
···
On 4/16/06 2:38 AM, "Stephen Waits" <steve@waits.net> 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"
Thanks,
Steve
Jim Weirich 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
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
Maybe you could write a shell script to do it?
···
On Sunday 16 April 2006 07:27 pm, Stephen Waits wrote:
Jim Weirich 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
Stephen Waits 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 Weirich
--
Posted via http://www.ruby-forum.com/\.
Tom Copeland 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 Weirich
--
Posted via http://www.ruby-forum.com/\.
David Corbin 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
Tom Copeland 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.
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.
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.
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
···
On Wed, 2006-04-19 at 09:34 +0900, Jim Weirich wrote: