Permalink
Browse files

use rake tasks to set the default environment variables. fixes #2126

  • Loading branch information...
tenderlove committed Jul 21, 2011
1 parent bb7e355 commit 5b6121aa3428f4fc0f12fd797abde143b97650fb
Showing with 10 additions and 10 deletions.
  1. +10 −10 actionpack/lib/sprockets/assets.rake
@@ -1,16 +1,16 @@
namespace :assets do
+ # Ensures the RAILS_GROUPS environment variable is set
+ task :ensure_env do
+ ENV["RAILS_GROUPS"] ||= "assets"
+ end
+
desc "Compile all the assets named in config.assets.precompile"
- task :precompile do
- if ENV["RAILS_GROUPS"].to_s.empty?
- ENV["RAILS_GROUPS"] = "assets"
- Kernel.exec $0, *ARGV
- else
- Rake::Task["environment"].invoke
- Sprockets::Helpers::RailsHelper
+ task :precompile => :ensure_env do
+ Rake::Task["environment"].invoke
+ Sprockets::Helpers::RailsHelper
- assets = Rails.application.config.assets.precompile
- Rails.application.assets.precompile(*assets)
- end
+ assets = Rails.application.config.assets.precompile
+ Rails.application.assets.precompile(*assets)
end
desc "Remove compiled assets"

5 comments on commit 5b6121a

@josevalim

This comment has been minimized.

Show comment Hide comment
@josevalim

josevalim Aug 14, 2011

Contributor

Bro, this is not the same at all. :ensure_env is not doing what we expect because once we on this part of the code, RAILS_GROUPS was already used. So setting it makes no difference at all. I am impressed no test broke as I remember writing tests specifically for this.

Contributor

josevalim replied Aug 14, 2011

Bro, this is not the same at all. :ensure_env is not doing what we expect because once we on this part of the code, RAILS_GROUPS was already used. So setting it makes no difference at all. I am impressed no test broke as I remember writing tests specifically for this.

@tenderlove

This comment has been minimized.

Show comment Hide comment
@tenderlove

tenderlove Aug 14, 2011

Member

Where is it used? We should arrange the rake tasks to guarantee that it's set before it's used.

Shelling out again is a poor solution. It has many problems including the fact that ARGV can be modified, and that rake --trace becomes useless.

Member

tenderlove replied Aug 14, 2011

Where is it used? We should arrange the rake tasks to guarantee that it's set before it's used.

Shelling out again is a poor solution. It has many problems including the fact that ARGV can be modified, and that rake --trace becomes useless.

@josevalim

This comment has been minimized.

Show comment Hide comment
@josevalim

josevalim Aug 14, 2011

Contributor
Contributor

josevalim replied Aug 14, 2011

@spastorino

This comment has been minimized.

Show comment Hide comment
@spastorino

spastorino Aug 14, 2011

Member

@tenderlove bro I agree with you but as I said on the email this task is late on the boot process.
I'm still thinking that this https://github.com/ruby/ruby/blob/trunk/lib/optparse.rb#L880 is a bug and a dup should be executed over it.
Anyway as I said I agree with you that something seems bad :(

Member

spastorino replied Aug 14, 2011

@tenderlove bro I agree with you but as I said on the email this task is late on the boot process.
I'm still thinking that this https://github.com/ruby/ruby/blob/trunk/lib/optparse.rb#L880 is a bug and a dup should be executed over it.
Anyway as I said I agree with you that something seems bad :(

@tenderlove

This comment has been minimized.

Show comment Hide comment
@tenderlove

tenderlove Aug 15, 2011

Member

@spastorino you can't prevent things from modifying ARGV. optparse does it, rake used to do it, (I'm sure old test/unit does too).

I'll try to figure out something. :-(

Member

tenderlove replied Aug 15, 2011

@spastorino you can't prevent things from modifying ARGV. optparse does it, rake used to do it, (I'm sure old test/unit does too).

I'll try to figure out something. :-(

Please sign in to comment.