Mongrel users - Jun 2006 - Gem versioning and auto installs

Gem drives me daft sometimes.

It gives you this wonderful ability to specify a platform for a gem, but
forgets to provide a command line switch to select the platform. Politely it
asks you, which is all very well when you are installing on one machine
interactively, but no good at all on a cluster of 15 machines from a
Capistrano script.

Is there any way to get gem to automatically select the correct platform for
a particular version of Mongrel?

Failing that can I respectively request slightly different version numbers
for the differing platforms to assist automatic installs.

Thanks

-- 
Neil Wilson
Aldur Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060603/69e470da/attachment.htm

On Sat, 2006-06-03 at 09:02 +0100, Neil Wilson wrote:
> Gem drives me daft sometimes.
> 
> It gives you this wonderful ability to specify a platform for a gem,
> but forgets to provide a command line switch to select the platform.
> Politely it asks you, which is all very well when you are installing
> on one machine interactively, but no good at all on a cluster of 15
> machines from a Capistrano script.
> 
> Is there any way to get gem to automatically select the correct
> platform for a particular version of Mongrel?
> 
> Failing that can I respectively request slightly different version
> numbers for the differing platforms to assist automatic installs.
You''ve got two options at the moment:

1) Manually grab the version you want and then install the gem file.
I''d do it like this:

	$ wget \
 http://rubyforge.org/frs/download.php/9700/mongrel-0.3.12.4.gem
	$ gem install mongrel-0.3.12.4.gem

2) Install the pre-release.  This is always just one version.  It''s
released fairly frequently but we try to keep it stable.  You can do
this with:

	$ gem install mongrel --source=http://mongrel.rubyforge.org/releases/


If neither of these are good, and other people would like to just
install the current version without a prompt, then I can setup
a /current/ gem source that''s like /releases/ but it just contains the
current production release.  But, at least try the other two options
before making me do work. :-)


-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/

On 03/06/06, Zed Shaw <zedshaw at zedshaw.com>
wrote:
>
> You''ve got two options at the moment:
>
> 1) Manually grab the version you want and then install the gem file.
> I''d do it like this:
>
>        $ wget \
> http://rubyforge.org/frs/download.php/9700/mongrel-0.3.12.4.gem
>        $ gem install mongrel-0.3.12.4.gem


Tried that - local gem install doesn''t handle dependencies
automatically :-(

Not at all keen on pre-release for various reasons.

The third option is this ugly hack that I cobbled together this afternoon
right before I ran out of hair to pull out. Those with a weak stomach should
look away now.

sudo sh -c "gem install mongrel -v 0.3.12.4 </dev/null 2>&1|
    sed -ne ''/(ruby)/s/ \([0-9][0-9]*\).*/\1/p'' |
    gem install -y --no-rdoc -v 0.3.12.4 mongrel"




-- 
Neil Wilson (neil at aldur.co.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060603/dc174c9d/attachment.htm

The way the ''mysql'' gem handles this is pretty good. It adds
the ISO date to
the version number for platforms other than ''ruby'', viz:

Select which gem to install for your platform (i686-linux)
 1. mysql 2.7.2006.05.10 (mswin32)
 2. mysql 2.7.2006.04.21 (mswin32)
 3. mysql 2.7 (ruby)
 4. mysql 2.6 (ruby)
 5. mysql 2.5.1 (ruby)
 6. Cancel installation
>

On 03/06/06, Zed Shaw <zedshaw at zedshaw.com>
wrote:
>
>
> If neither of these are good, and other people would like to just
> install the current version without a prompt, then I can setup
> a /current/ gem source that''s like /releases/ but it just contains
the
> current production release.  But, at least try the other two options
> before making me do work. :-)
>
>
-- 
Neil Wilson (neil at aldur.co.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060603/f1366f49/attachment.htm

On Sat, 2006-06-03 at 22:34 +0100, Neil Wilson wrote:
> The way the ''mysql'' gem handles this is pretty good. It
adds the ISO
> date to the version number for platforms other than
''ruby'', viz:
> 
> Select which gem to install for your platform (i686-linux)
>  1. mysql 2.7.2006.05.10 (mswin32)
>  2. mysql 2.7.2006.04.21 (mswin32)
>  3. mysql 2.7 (ruby)
>  4. mysql 2.6 (ruby)
>  5. mysql 2.5.1 (ruby)
>  6. Cancel installation
> >
Uh, how does putting a date on the mswin32 gem help you?  You still have
a prompt here, you''d still have to pick the latest ruby version, and it
would just complicate things.  I guess I don''t see what this does for
you.

Another option is for you to simply install it like normal on one
machine, and then just rsync your gem directory to the other machines.
Considering there are quite a few ways to clone software from one
machine to a group of others (PIKT, rsync, cfengine, unison to name a
few), I think you should check out a few of those first.  It might be
that capistrano and gems just isn''t really the right tool for this
job.\

-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/

> Tried that - local gem install doesn''t handle dependencies
automatically
Is that much of an issue for deployment, though?  Seems like you want to
know precisely what''s installed on production servers, and having
dependencies resolved for you isn''t quite so much of an issue.

 - James Moore

Because I can do ''gem install -v 2.7 mongrel'' and pick up just
the ruby
version, or ''gem install -v 2.7.2006.05.10 mongrel'' and pick
up the mswin
version - automatically. I can''t do that if the
''ruby'' and ''mswin'' versions
both have identical version number. It''s the lack of a gem switch to
pick up
the platform that is causing the problem, so if you move the differentiator
to the version number it works around the problem. I still have to specify
the version number, but at least if I do gem gets on with the job.

Using a version number indicator at the end would achieve the same effect -
say 1 for Linux, 2 for ms win, thus:

0.3.12.4-1
0.3.12.4-2

(assuming you can have dashes in gem version numbers - I haven''t tried
it!)

On 03/06/06, Zed Shaw <zedshaw at zedshaw.com>
wrote:
>
> Uh, how does putting a date on the mswin32 gem help you?  You still have
>
-- 
Neil Wilson (neil at aldur.co.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060604/8bb6c14f/attachment.htm

Full specification gets  remarkably unmanageable when you decide to change
something. Having tried it both ways the design decision I took was to stick
to specifying the major software items as lightly as possible and let the
machines deal with pulling in the rest. Otherwise your list of modules is
four foot long and you end up being unable to see the wood for the trees.

My goal is automation with flexibility. What gets in the way is tools that
assume there is a human sat at a terminal or, worse, clicking with a mouse.
gem is at fault here, not mongrel but nobody seems to be fixing gem at the
moment - the patches to fix the platform problem are already in the gem
tracker.

On 04/06/06, James Moore <banshee at banshee.com>
wrote:
>
> > Tried that - local gem install doesn''t handle dependencies
automatically
>
> Is that much of an issue for deployment, though?  Seems like you want to
> know precisely what''s installed on production servers, and having
> dependencies resolved for you isn''t quite so much of an issue.
>
> - James Moore
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Neil Wilson ( neil at aldur.co.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060604/5e76ebd2/attachment.htm

> Full specification gets? remarkably unmanageable when you decide to change
> something. 
I suspect you''re going to change your mind fairly soon.

Virtually everywhere I''ve been has a system for stamping out production
servers that look precisely the way you want them to.  Letting production
machines figure out what they''re supposed to install on their own is
going
to come back and sink its rabid little teeth into your ankles at some point
in the very near future.  Every time a problem comes up you''re going to
need
to convince yourself that it''s not an environment issue on that
specific
machine.

I''m not a system administrator, but I''ve worked with teams of
really good
sysadmins at some reasonably large sites (tens of millions of user
accounts).  Any time I have a sysadmin-type problem, I imagine myself in a
meeting with them, explaining what the deployment process for my software
looks like.  They''d be asking things like:

Q - So, when a problem comes up, how do we know it''s not because
machine X
is ever-so-slightly different than machine Y? 
A - Uh, mmm, er...

Q - You really expect us to pull live updates from the net, without checking
them first?  With customer data?
A - Err, ah...

Q - And what happens when we get a media mention of our product and we have
to install three new servers _right now_ and the network resource we''re
supposed to pull these dependencies from is down?  (Yes, this happens.)  Or
we''ve just scheduled a block of time for system updates? 
You''ve just
trashed our schedule, right? 
A - Gah, mmm...

Q - And what do we do when one of these so-called "dependencies"
breaks
something that we thought was unrelated?
A - <dead air>

I hate those meetings :-). 

 - James Moore

I do agree with the basic point that installers should never under any
circumstances ask a human being anything, though.  Better to just fail if
the default install isn''t sufficient.

In particular, it''s weird to me that gem install mongrel comes up with:

C:\radw\rv>gem install mongrel
Attempting local installation of ''mongrel''
Local gem file not found: mongrel*.gem
Attempting remote installation of ''mongrel''
Updating Gem source index for: http://gems.rubyforge.org
Select which gem to install for your platform (i386-mswin32)
 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)
 5. mongrel 0.3.12.2 (ruby)
 6. mongrel 0.3.12.2 (mswin32)
 7. mongrel 0.3.12.1 (mswin32)
 8. mongrel 0.3.12.1 (ruby)
 9. mongrel 0.3.12 (mswin32)
 10. mongrel 0.3.12 (ruby)
 11. mongrel 0.3.11 (ruby)
 12. mongrel 0.3.11 (mswin32)
 13. mongrel 0.3.10.1 (ruby)
 14. mongrel 0.3.10 (ruby)
 15. mongrel 0.3.9 (ruby)
 16. mongrel 0.3.8 (ruby)
 17. mongrel 0.3.8 (mswin32)
 18. mongrel 0.3.7.1 (ruby)
 19. mongrel 0.3.7.1 (mswin32)
 20. mongrel 0.3.7 (ruby)
 21. mongrel 0.3.6 (ruby)
 22. mongrel 0.3.6 (mswin32)
 23. mongrel 0.3.5 (ruby)
 24. mongrel 0.3.5 (mswin32)
 25. mongrel 0.3.4 (mswin32)
 26. mongrel 0.3.4 (ruby)
 27. mongrel 0.3.3 (ruby)
 28. mongrel 0.3.2 (ruby)
 29. mongrel 0.3.1 (ruby)
 30. mongrel 0.3 (ruby)
 31. mongrel 0.2.2 (ruby)
 32. mongrel 0.2.1 (ruby)
 33. mongrel 0.2.0 (ruby)
 34. Cancel installation
>
Seems like you should just install whatever the latest stable version is.
If someone needs to install something like mongrel 0.3.1, they should know
how to do that on their own.

(This list is a mongrel thing, not a gem thing, right?)

 - James

Nah. It''s a gem thing due to the multiple platforms within the single
gem.


On 04/06/06, James Moore <banshee at banshee.com>
wrote:
>
>
> (This list is a mongrel thing, not a gem thing, right?)
> n/listinfo/mongrel-users
>


-- 
Neil Wilson (neil at aldur.co.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20060604/37cdfd97/attachment.htm