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.gemTried 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 automaticallyIs 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
Possibly Parallel Threads
- Rails, Ubuntu dapper & Mongrel > uninitialized constant Mongrel::HttpHandler error
- Finally! Mongrel 0.3.13.4 Official (for Unix)
- Mongrel Web Server 0.3.12.2 -- Iron Mongrel (Parser Fix)
- I am a newbie and I would like some help deciding what operating system
- Mongrel 0.3.13.4 -- PIDs Work, Win32 Gem