From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.49.16 with SMTP id t16cs41021qcf; Thu, 2 Sep 2010 05:02:23 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCP_V2_zRBRDMpP7jBBoEqBeUjQ@googlegroups.com designates 10.229.78.197 as permitted sender) client-ip=10.229.78.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCP_V2_zRBRDMpP7jBBoEqBeUjQ@googlegroups.com designates 10.229.78.197 as permitted sender) smtp.mail=rack-devel+bncCP_V2_zRBRDMpP7jBBoEqBeUjQ@googlegroups.com; dkim=pass header.i=rack-devel+bncCP_V2_zRBRDMpP7jBBoEqBeUjQ@googlegroups.com Received: from mr.google.com ([10.229.78.197]) by 10.229.78.197 with SMTP id m5mr3294236qck.22.1283428942776 (num_hops = 1); Thu, 02 Sep 2010 05:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:received:received:mime-version :subject:from:in-reply-to:date:message-id:references:to:x-mailer :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; bh=f4SgxGr7iG8nLkK64765llJYOeImh6I0CoHScW31P/8=; b=lfpf3MhK6IVENbLBH81tqbK/30bW6iVYOri9Vnbw1h/DWAu/5JBXzfMaRVOdb8xx7K 1RdFTD7GdzwQO/U2//m79KVUTT4ihQt4Ck88Hg8IFITqQvrMjhkdYaMywb4A9iKG7ZZX cwklLT2L7QB8BkH5LAqEEab4XmkDA1KyjAL2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:subject:from:in-reply-to:date :message-id:references:to:x-mailer:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; b=Ubvc9JbK3NPMlp+fQa2zjYqql1ckbvwPDjG5qv0NZ232YW0l40GUVa3aHkK3HqzygB IC9uEMs/p51gE5tnQmxKlAxV2R021RJwsqcyIQxYYGKHwy38Ga3FbO9gOkIyM2JxOw6y avnKIh/RK90GBjPbpc/KoMTw/W/NUpaZ2orUU= Received: by 10.229.78.197 with SMTP id m5mr647135qck.22.1283428940244; Thu, 02 Sep 2010 05:02:20 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.229.173.155 with SMTP id p27ls273264qcz.3.p; Thu, 02 Sep 2010 05:02:18 -0700 (PDT) Received: by 10.229.236.65 with SMTP id kj1mr819652qcb.19.1283428938539; Thu, 02 Sep 2010 05:02:18 -0700 (PDT) Received: by 10.229.236.65 with SMTP id kj1mr819650qcb.19.1283428938249; Thu, 02 Sep 2010 05:02:18 -0700 (PDT) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by gmr-mx.google.com with ESMTP id 2si221043qci.2.2010.09.02.05.02.17; Thu, 02 Sep 2010 05:02:17 -0700 (PDT) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.216.53 as permitted sender) client-ip=209.85.216.53; Received: by mail-qw0-f53.google.com with SMTP id 5so474555qwe.40 for ; Thu, 02 Sep 2010 05:02:17 -0700 (PDT) Received: by 10.229.52.32 with SMTP id f32mr5973666qcg.265.1283428885132; Thu, 02 Sep 2010 05:01:25 -0700 (PDT) Received: from [192.168.101.3] ([199.172.230.17]) by mx.google.com with ESMTPS id r38sm385519qcs.2.2010.09.02.05.01.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Sep 2010 05:01:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: Bootstrapping rackup with multiple rack gems installed From: James Tucker In-Reply-To: <0257a5a4-9afb-4abf-bb46-b14fbbc57c38@s9g2000yqd.googlegroups.com> Date: Thu, 2 Sep 2010 09:01:20 -0300 Message-Id: <4B5D8072-3F20-40B6-83DB-09336DB8279D@gmail.com> References: <0257a5a4-9afb-4abf-bb46-b14fbbc57c38@s9g2000yqd.googlegroups.com> To: rack-devel@googlegroups.com X-Mailer: Apple Mail (2.1081) X-Original-Sender: jftucker@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.216.53 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 1 Sep 2010, at 16:14, Joshua Peek wrote: > This came up as an issue in Rails 2.3 along with the release of Rack > 1.2. Rails 2.3 is locked to Rack 1.0 so if Rack 1.2 is activated > before hand, Rails will fail to boot. Most people now have Rack 1.0 > and 1.2 both installed. In a prefect rubygems world everything would > work fine. (This is why I don't use RG, but a ton of people are still > using Rails 2.3 and RG) It's not RubyGems fault if people don't use dependency manifests and/or = call Kernel#gem. RubyGems activates dependencies in order to avoid = cross-dependency failures at runtime - this "error" is protecting = against potentially far far more horrible bugs. Dependency management is = not a "perfect world". If you have a serious suggestion about how this = could possibly be solved in RubyGems without removing features or = failing critical use cases, please pass your thoughts on as if you can = genuinely solve it, I'll get it committed to RubyGems immediately. > Starting Rails with `script/server` works fine because Rails boots > first. You can start Rails with `rackup` but you have to make sure you > are using the matching rack version with `rackup _1.0.1_` which is > kind of lame though. The major issue is with servers like unicorn and > passenger which have their own bootstrapping scripts. If they support multiple versions of rack, then they need to load the = version they want as configured by the user. > If you boot a Rails 2.3 app with `unicorn` and Rack 1.2 is installed, > Unicorn attempts to require rack pulling in the latest version since > it doesn't know any better then boots Rails causing the gem conflict. > Similar deal with passenger. >=20 > Unicorn has a valid reason for requiring rack since it needs to load > Rack::Builder before it evals the config.ru file. The use of the > builder dsl in .ru files causes a serious fundamental problem with > loading rack. The application can never specify which version of rack > to use since it has to be chosen before its loaded. >=20 > Possible workarounds: >=20 > 1) Always bootstrap with the correct version of rackup with `rackup > _1.0.0_`, `/path/to/rack/1.0.0/bin/rackup`, etc. > 2) Unicorn and Passenger should allow you to specify which rack > version to use. > 3) Specify a load path or environment file on boot that setups the > correct paths or activates the right version of rack. This could be > done by requiring an environment that loads Bundler or similar tools. > 4) Hacky version independent version of rackup. I hacked this up to > demonstration how http://gist.github.com/560926 you can lazily > evaluate the builder dsl after the application loads. >=20 > Are there anymore workarounds? Whats the suggested fix? I'd like to > hear some opinions on the whole bootstapping matter. I generally write independent boostrap code for applications whenever = necessary, to me this is as important a practice as writing proper build = scripts and ensuring that 'make' or 'rake' from the top level boostraps, = builds, and runs tests or the application as much without fail as is = possible. I know many developers find this diligent practice "boring", = but it is very important. Bundler made this all a hell of a lot easier. The idea from 4 could maybe be extended to pushing the whole Rackup and = Rack::Builder DSL (which seldom changes, and is not that tied to Rack = spec or the Rack application API) to another gem. That gem needn't = depend on rack (in theory it could load other things), and could provide = a DSL method to load a specific version of rack dynamically. This would = mean that users could once again take the easy way out, avoid writing = manifests or builds, and simply spec a rack version in the rackup DSL. Something like this could work: rack '1.0.1' # calls Kernel#gem with 'rack', '1.0.1' map '/' do ... In scenarios where RubyGems is not in use, the users would either have = to load a plugin that alters the Kernel#gem call to something else = (although I don't know of another package manager in ruby that actually = manages dependencies properly at runtime), otherwise if it's using the = filesystem namespace for versioning (as most alternatives do), one could = just omit the call, and rely on a later call to "require 'rack'".=