All, Caveat: New user naivete to follow. I''m starting an application in Rails and I can''t use Gems. (There are legal implications in deploying unknown code here.) But Rails seems to have an extraordinary dependence on Gems. If I say ''rails PROJECT'', then the PROJECT directory gets created with supporting scripts, etc., but since they work internally relative to their own location, they don''t find every thing they need (which would be offset by ''../''). So, almost everything that I do goes down the Gems require branches. I find it hard to believe that the Rails creators intended to duplicate the entire Rails installation inside the application, but I always seem to hit this wall. Are there standard ways to avoid this? Non-standard suggestions? Thanks. ,Doug -- Posted via http://www.ruby-forum.com/.
Not entirely sure what you mean here ... if you can''t use unknown code how can you get away with using Rails? (for a given value of unknown). If its a download issue, gems can be installed from the local machine too. On 8/15/06, Douglas Lewan <d_lewan2000@yahoo.com> wrote:> All, > > Caveat: New user naivete to follow. > > I''m starting an application in Rails and I can''t use Gems. (There are > legal implications in deploying unknown code here.) But Rails seems to > have an extraordinary dependence on Gems. > > If I say ''rails PROJECT'', then the PROJECT directory gets created with > supporting scripts, etc., but since they work internally relative to > their own location, they don''t find every thing they need (which would > be offset by ''../''). So, almost everything that I do goes down the Gems > require branches. > > I find it hard to believe that the Rails creators intended to duplicate > the entire Rails installation inside the application, but I always seem > to hit this wall. > > Are there standard ways to avoid this? Non-standard suggestions? > > Thanks. > > ,Doug > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
to add a third option: if the concern is that you don''t want to rely on code outside your app''s distribution, you can "rake freeze_gems" to import the current gems into your app space. you''d still be using gems, but they''d be gems under your control, not reliant on whatever someone has installed somewhere (n.b. if you need to update rails you have to undo and redo this to pick up the current version) -faisal On Aug 15, 2006, at 11:18 AM, Richard Conroy wrote:> Not entirely sure what you mean here ... if you can''t use unknown > code how can you get away with using Rails? (for a given value > of unknown). > > If its a download issue, gems can be installed from the local machine > too. > > On 8/15/06, Douglas Lewan <d_lewan2000@yahoo.com> wrote: >> All, >> >> Caveat: New user naivete to follow. >> >> I''m starting an application in Rails and I can''t use Gems. (There >> are >> legal implications in deploying unknown code here.) But Rails >> seems to >> have an extraordinary dependence on Gems. >> >> If I say ''rails PROJECT'', then the PROJECT directory gets created >> with >> supporting scripts, etc., but since they work internally relative to >> their own location, they don''t find every thing they need (which >> would >> be offset by ''../''). So, almost everything that I do goes down >> the Gems >> require branches. >> >> I find it hard to believe that the Rails creators intended to >> duplicate >> the entire Rails installation inside the application, but I always >> seem >> to hit this wall. >> >> Are there standard ways to avoid this? Non-standard suggestions? >> >> Thanks. >> >> ,Doug >> >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Thanks for the good suggestions. You''re right "unknown code" is definitely a variable. The point is that we''ll get through development and test and we need to be absolutely sure that what''s deployed is what''s tested. If the code doesn''t change, then we know something about the bugs that we''ve deployed; if it does, then we don''t. My client can live with known flaws, but unknown flaws puts him in a very bad position. A large-scale upgrade is a different story. When we have to do that, we''re already at the start of a big upheaval. Thanks again. ,Doug -- Posted via http://www.ruby-forum.com/.
I see, the issue is that you wish to use the same versions of various libs in the field as you used in your test lab. So basically getting the latest gems is not an option. Have a good look (and experiment with) using gems to install extensions that are on the local file system. Basically not letting gems have a look on the web. That should give you a precise deployment - you bundle the versioned libs with your app, and *only* gem install those. On 8/15/06, Douglas Lewan <d_lewan2000@yahoo.com> wrote:> Thanks for the good suggestions. > > You''re right "unknown code" is definitely a variable. The point is that > we''ll get through development and test and we need to be absolutely sure > that what''s deployed is what''s tested. If the code doesn''t change, then > we know something about the bugs that we''ve deployed; if it does, then > we don''t. My client can live with known flaws, but unknown flaws puts > him in a very bad position. > > A large-scale upgrade is a different story. When we have to do that, > we''re already at the start of a big upheaval. > > Thanks again. > > ,Doug > > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
i think you can even install gems of a user-specified version via a gem option, if that helps. otherwise, the freeze_gems task could be useful. you execute it on your dev machine and have the rails gems extraved into vendor/rails, so when you just copy over your app dir, youll have exactly the same version of rails installed and used as in dev. 2006/8/16, Richard Conroy <richard.conroy@gmail.com>:> > I see, the issue is that you wish to use the same versions of > various libs in the field as you used in your test lab. > > So basically getting the latest gems is not an option. > > Have a good look (and experiment with) using gems to > install extensions that are on the local file system. Basically > not letting gems have a look on the web. That should give > you a precise deployment - you bundle the versioned libs > with your app, and *only* gem install those. > > > On 8/15/06, Douglas Lewan <d_lewan2000@yahoo.com> wrote: > > Thanks for the good suggestions. > > > > You''re right "unknown code" is definitely a variable. The point is that > > we''ll get through development and test and we need to be absolutely sure > > that what''s deployed is what''s tested. If the code doesn''t change, then > > we know something about the bugs that we''ve deployed; if it does, then > > we don''t. My client can live with known flaws, but unknown flaws puts > > him in a very bad position. > > > > A large-scale upgrade is a different story. When we have to do that, > > we''re already at the start of a big upheaval. > > > > Thanks again. > > > > ,Doug > > > > > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Michael Siebert <info@siebert-wd.de> www.stellar-legends.de - Weltraum-Browsergame im Alpha-Stadium -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060816/8bc2aafe/attachment-0001.html