Has there been discussion about Rick Olsen's gems plugin (http://www.agilewebdevelopment.com/plugins/gems) from being included into core?
If not...
Can we include Rick's gems plugin code (a task and <10 lines of code) into core please? If yes, I'll whip up a patch.
Its generic and wonderful.
Has there been discussion about Rick Olsen's gems plugin (http://www.agilewebdevelopment.com/plugins/gems) from being included into core?
If not...
Can we include Rick's gems plugin code (a task and <10 lines of code) into core please? If yes, I'll whip up a patch.
Its generic and wonderful.
Perhaps rick can share his thoughts, assuming it's nice and seamless, I have no objections.
Perhaps rick can share his thoughts, assuming it's nice and seamless, I have no objections.
The actual gem:freeze task itself is very handy IMO. The only part I'm unsure of is the code that automatically inserts vendor/* folders into the LOAD_PATH. I assume if you use the gems plugin you want this, but I don't know if it's a good assumption to make for all apps.
This is the chunk of code I'm referring to: http://svn.techno-weenie.net/projects/mephisto/trunk/vendor/plugins/a_gems/init.rb
Thoughts?
At the moment I’m investigating a structure for supporting tasks in gems being applied to rails apps. Give me a few days to think about this a bit.
Nic
Rick Olson wrote:
> Perhaps rick can share his thoughts, assuming it's nice and seamless, > I have no objections.
The actual gem:freeze task itself is very handy IMO. The only part I'm unsure of is the code that automatically inserts vendor/* folders into the LOAD_PATH. I assume if you use the gems plugin you want this, but I don't know if it's a good assumption to make for all apps.
It might be cleaner to dump the gems in /vendor/gems and thus load them confidently from there.
Nic
It might be cleaner to dump the gems in /vendor/gems and thus load them confidently from there.
Yeah, that would seem to be a nice, safe option.
For now, I think I'd like to suggest that we hold off on adding any more features to 1.2. Let's get 1.2 stable and then talk about what to add to the next release.
To that end, I think both gems:freeze and the ARTS stuff ought to wait.
- Jamis
I think that's a mighty fine idea, neither plugin is monkeypatching too heavily, so they're unlikely to get busted by a 1.2 release.
To that end, I think both gems:freeze and the ARTS stuff ought to wait.
+1. We have a finite list of things we want done before release now. Otherwise this will just be the never ending story (II, the one that sucked).
There is a difference though, gems:freeze is really new functionality
and ARTS is a proper way to test existing functionality.
I’ve no issue with gems:freeze waiting til post-1.2.
Nic
Are we to take from this that you actually *liked* the first one? 
“Neverending story” - the book - was actually great! It was the movie that sucked; even the author said that, embarrassed he sold the rights in the first place.
Dr Nic wrote:
Rick Olson wrote: > > Perhaps rick can share his thoughts, assuming it's nice and seamless, > > I have no objections. > > The actual gem:freeze task itself is very handy IMO. The only part > I'm unsure of is the code that automatically inserts vendor/* folders > into the LOAD_PATH. I assume if you use the gems plugin you want > this, but I don't know if it's a good assumption to make for all apps.
It might be cleaner to dump the gems in /vendor/gems and thus load them confidently from there.
The upside of all gems going into a separate folder is we can easily find all rake tasks:
Add to rails/lib/tasks/rails.rb: Dir["./vendor/gems/*/**/*.rake"].sort.each { |ext| load ext }
Rails-trac ticket: http://dev.rubyonrails.org/ticket/6410 * This ticket is just for the above trivial change, and not gems:freeze as a whole *
Nic