So Rake 0.7 allows for namespaces in actions. It''s mighty nice. rake db:schema:import and rake db:schema:export whips the llama''s ass on db_schema_import/export. It makes it much to organize tasks. Yay, yay. But how does this relate to backwards compatibility? What would happen if the next release changed all the tasks over to be namespaced? Who and want would break? I''m coming up short with ideas on where it would be a problem, but I''d like to hear if others have some dependencies on the specific rake names. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
Include a backwards-compatability task library with the old names that just delegates to the new modularized ones? Might be overkill if it''s not going to be a serious problem but it''s relatively easy to do. On 2/27/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:> So Rake 0.7 allows for namespaces in actions. It''s mighty nice. rake > db:schema:import and rake db:schema:export whips the llama''s ass on > db_schema_import/export. It makes it much to organize tasks. Yay, yay. > > But how does this relate to backwards compatibility? What would happen > if the next release changed all the tasks over to be namespaced? Who > and want would break? I''m coming up short with ideas on where it would > be a problem, but I''d like to hear if others have some dependencies on > the specific rake names. > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
> Include a backwards-compatability task library with the old names that > just delegates to the new modularized ones? Might be overkill if it''s > not going to be a serious problem but it''s relatively easy to do.The problem is what a mess that''ll make of "rake -T". So before making such a mess, I want to have some good reasons for doing so ;) -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
Hi,
Anyone who has modified the flow of tasks when building rail apps or
who have built their own tasks that rely on rails tasks is going to be
bitten. For example, almost all of my rails apps have something
similar to the example below. Also - almost all of my custom tasks
will depend upon rails tasks by name and they will probably break.
Adding a backwards portability layer layer will not really work in
many circumstances (like example below) unless the new-style tasks
invoke the old-style tasks to do the work which is just messy.
However IMHO the benefit is worth the break as long as it is well
documented in changelog.
----------------------------------------------------------------
module Rake
class Task
def remove_prerequisite(task_name)
name = task_name.to_s
@prerequisites.delete(name)
end
end
end
Rake::Task.lookup(:test_units).remove_prerequisite(:prepare_test_database)
Rake::Task.lookup(:test_functional).remove_prerequisite(:prepare_test_database)
Rake::Task.lookup(:test_units).enhance([:environment])
Rake::Task.lookup(:test_functional).enhance([:environment])
----------------------------------------------------------------
On 2/27/06, David Heinemeier Hansson <david.heinemeier@gmail.com>
wrote:> > Include a backwards-compatability task library with the old names that
> > just delegates to the new modularized ones? Might be overkill if
it''s
> > not going to be a serious problem but it''s relatively easy to
do.
>
> The problem is what a mess that''ll make of "rake -T". So
before making
> such a mess, I want to have some good reasons for doing so ;)
> --
> David Heinemeier Hansson
> http://www.loudthinking.com -- Broadcasting Brain
> http://www.basecamphq.com -- Online project management
> http://www.backpackit.com -- Personal information manager
> http://www.rubyonrails.com -- Web-application framework
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
--
Cheers,
Peter Donald
Blog: http://www.RealityForge.org
On 2/26/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:> So Rake 0.7 allows for namespaces in actions. It''s mighty nice. rake > db:schema:import and rake db:schema:export whips the llama''s ass on > db_schema_import/export. It makes it much to organize tasks. Yay, yay. > > But how does this relate to backwards compatibility? What would happen > if the next release changed all the tasks over to be namespaced? Who > and want would break? I''m coming up short with ideas on where it would > be a problem, but I''d like to hear if others have some dependencies on > the specific rake names.Perhaps a better question might be: "Is this change likely to get easier or harder after Rails 1.1?" If it''s going to happen, it should probably happen before too many more users reference the old task names. Presumably SwitchTower would break, but the fix shouldn''t exactly be rocket science.
> Include a backwards-compatability task library with the old names that > just delegates to the new modularized ones? Might be overkill if it''s > not going to be a serious problem but it''s relatively easy to do.This is the way we''ll go since I can make the old tasks not show up in rake -T, but they''ll still be there. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On Feb 26, 2006, at 6:29 PM, David Heinemeier Hansson wrote:> The problem is what a mess that''ll make of "rake -T". So before making > such a mess, I want to have some good reasons for doing so ;)I thought the Rails 1 series was supposed to maintain compatibility. Apart from being cool, what benefits to these changes bring to the _users_ of Rails? Dave
On 2/27/06, Dave Thomas <dave@pragprog.com> wrote:> Apart from being cool, what benefits to these changes bring to the > _users_ of Rails?So you''re saying "cool" isn''t a benefit in itself. ;-) (But of course, I agree, if it''s not backwards compatible it shouldn''t be done.)
> So you''re saying "cool" isn''t a benefit in itself. ;-) > > > (But of course, I agree, if it''s not backwards compatible it shouldn''t be done.)I agree too, and the change currently being proposed is backwards compatible for exactly this reason. David''s rake -T concerns wouldn''t be reason enough to break backwards compatibility, but it turns out that they can be satisfied anyway. -- Cheers Koz
> I thought the Rails 1 series was supposed to maintain compatibility.See the decision from 1:30 minutes ago. The old tasks will still work, "rake -T" will just only show the new names.> Apart from being cool, what benefits to these changes bring to the > _users_ of Rails?Better coherence in the face of a larger number of tasks. This will allow SwitchTower to more easily populate the remote: namespace with all its tasks instead of just a cherry-pick and then remote_exec for the rest. So the same benefit that namespaces always bring: Order to the madness. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework