On 10/21/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > > This would allow dynamic control over RAILS_GEM_VERSION and the > > Version Specification passed to the RubyGems 'gem' method for the > > rails gem. For example, users could test an app or plugin in a > > Continuous Integration environment which performs automated regression > > testing against various old Rails versions. > > I'm just not sure that there are a whole lot of use cases that need > this kind of flexibility before environment.rb gets hit.
Hi Koz, Thanks for the feedback! I'll respond to your points inline below. > > When I'm testing my apps against multiple rails releases I just use > symlinks in /vendor/rails pointing to various subversion checkouts. Symlinks aren't cross-platform. They are also harder to automate, especially in a Continuous Integration environment. With a hook to pre-initialize RAILS_GEM_PATH and load the gem on the path, you can control everything with an environment variable and not modify the filesystem/working copy at all - everything is in memory and the env var goes away after the build. The symlink approach is harder to automate and more intrusive - it would require the CI tool to manage the physical creation of the symlinks (and ensuring the existence of wherever they point to), and reseting them to the proper defaults (but what if the build fails? Hope your Ci tool has a good after-build-failure hook). IMHO, automating the use of multiple releases is easier with gems than modifying the filesystem under vendor, if only because of RubyGems built-in support for selecting any installed version on the fly. > > Are there any other common cases you have in mind? You could always > automate the patching of boot.rb for your gem installer app. Well, that would be ignoring the warning to not modify boot.rb, and I don't want to do that! Also, that would involve some ugly parsing and hacking of people's boot.rb (the hook needs to be after RAILS_ROOT is defined). What if boot.rb changes with a new Rails release (or has been customized by the user) and my regexp no longer matches? What if I have a bug and hose their boot.rb? Again, I think it's cleaner, safer and less intrusive to have preinitializer hook(s). No need to ignore warnings and modify boot.rb, and if I screw something up or users don't want my hook anymore, there's a well-defined place to find and delete it. Even if there's not a ton of use cases for this patch, there's not really any alternatives that address the problem well, and it's completely innocuous AFAIK, so I hope it can be considered in that light. > > -- > Cheers > > Koz Thanks again for the response, -- Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
