I notice that in the last week of 2.3.3 preparation the vendored rack
was removed, so we now need to install the gem.
Should rake rails:freeze:gems be extended to freeze in rack?
It was surprising to me that it this lateish change didn't maintain
what was effectively the old behaviour since rack had been bundled,
and GEM=rack rake gems:unpack won't freeze it in either currently
since (I assume) it's not listed as an environment dependency.
Cheers,
Will
I don't think that vendoring Rack will even *work* on Passenger - I
haven't tried it, but a casual reading of the FrameworkSpawner code
shows that it loads the Rails gem (in preload_rails). With 2.3.3, this
will blow up unless Rack is installed at the system level.
So encouraging users to freeze Rack will result in apps that break in
some environments but not others (even 'smart-lv2' vs 'smart' spawning).
--Matt Jones
It seems to work - I added rack to config.gem and unpacked it, and it
deployed fine into our Passenger server environment.
So as far as I can see, automatically adding rack to the list of gem
dependencies, and automatically unpacking rack when rake
rails:freeze:gems is run, would solve the problem?
Actually, just realised rack is still installed as a gem, so ignore me
- haven't tested out that scenario properly.
Personally I don't mind Phusion Passenger depending on or vendoring in
Rack, as long as all the Ruby HTTP servers work the same way (perhaps
too difficult a thing to ask).
Mongrel doesn't depend on Rack, so ActionPack does. That sort of puts
the ball in Rails' court, and accordingly makes it seem to me like we
must freeze in Rack when we freeze in Rails (since the whole point of
freezing in is that you don't need to deploy anything else to make the
app work - aside from the HTTP server you're using, the mongrel gem in
this example).
But, that currently doesn't really match Passenger, as you say. So, I
wonder if someone could make just as strong a case that Mongrel should
be changed to depend on Rack and ActionPack should not.
Thoughts?
Perhaps we need to assess which is more likely to lead to problems
with people deploying apps (which are not necessarily running latest
release of Rails). In other words, what's more likely to make
breaking changes that can't or won't be worked around - changes to the
API between HTTP server and Rack, or between Rack and Rails?
Looking at the number of commits Joshua had to make to keep Rails
up-to-date with Rack, I would have guessed the latter, in which case
yeah I'd still vote that we should vendor in Rack. People are more
likely to be able to upgrade Passenger, than they are to be able to
upgrade to the latest release of Rails just for updated Rack
compatibility.