Can I not reference from production.rb a constant in environment.rb?

I have the following constant in production.rb: GSA_EPLS_DATASOURCE = FILESTORE + “/” + “datafiles/gsa_epls.xml”

The constant FILESTORE is located in environment.rb: FILESTORE = “…/creditcompare_filestore/” + Rails.env

When I try to migrate my db on heroku I get this error which points to the line above in production.rb

uninitialized constant FILESTORE

So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments… I dont have to but would like to. Is there a way to do what I am trying to do?

I have the following constant in production.rb: GSA_EPLS_DATASOURCE = FILESTORE + "/" + "datafiles/gsa_epls.xml"

The constant FILESTORE is located in environment.rb: FILESTORE = "../creditcompare_filestore/" + Rails.env

When I try to migrate my db on heroku I get this error which points to the line above in production.rb

uninitialized constant FILESTORE

So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments... I dont have to but would like to. Is there a way to do what I am trying to do?

I see you already solved this, but you might look into something like SettingsLogic....

-philip

I have the following constant in production.rb:

GSA_EPLS_DATASOURCE = FILESTORE + “/” + “datafiles/gsa_epls.xml”

The constant FILESTORE is located in environment.rb:

FILESTORE = “…/creditcompare_filestore/” + Rails.env

When I try to migrate my db on heroku I get this error which points to the line above in production.rb

uninitialized constant FILESTORE

So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments… I dont have to but would like to. Is there a way to do what I am trying to do?

I see you already solved this, but you might look into something like SettingsLogic…

https://github.com/binarylogic/settingslogic

Hey Philip, that looks really cool - thanks for sharing. Not sure if you know, but my challenge is I push to heroku for staging (product owner review), but my production environment is elsewhere on our own Ubuntu server. Is there a way to create two production environments – say :production_heroku and :production_live? What I am doing now is having an extra production.rb off in a sub folder and when I push to the real production environment I tell capistrano to replace the existing production file which corresponds to heroku…

You want Capistrano’s multistage functionality…

http://weblog.jamisbuck.org/2007/7/23/capistrano-multistage

Create a “staging” environment file, entry in database.yml, and anywhere else you have development/production stuff…

Then you can do

cap staging deploy # to heroku

cap production deploy # to ubuntu

It’s perfect for this.

-philip

I realized I read to quickly… heroku has it’s own deployment setup. If you can change the environment you to deploy to on heroku then you could still do what I’ve said above. Otherwise, you could cheat and create :production (for heroku) and :really_really_production (for ubuntu) and then use what I’ve said above. Not quite as nice, but it would work.

I have the following constant in production.rb:

GSA_EPLS_DATASOURCE = FILESTORE + “/” + “datafiles/gsa_epls.xml”

The constant FILESTORE is located in environment.rb:

FILESTORE = “…/creditcompare_filestore/” + Rails.env

When I try to migrate my db on heroku I get this error which points to the line above in production.rb

uninitialized constant FILESTORE

So I am gathering that there is a load sequence issue. I am trying to keep FiLESTORE in highest level as it applies to all environments… I dont have to but would like to. Is there a way to do what I am trying to do?

I see you already solved this, but you might look into something like SettingsLogic…

https://github.com/binarylogic/settingslogic

Hey Philip, that looks really cool - thanks for sharing. Not sure if you know, but my challenge is I push to heroku for staging (product owner review), but my production environment is elsewhere on our own Ubuntu server. Is there a way to create two production environments – say :production_heroku and :production_live? What I am doing now is having an extra production.rb off in a sub folder and when I push to the real production environment I tell capistrano to replace the existing production file which corresponds to heroku…

You want Capistrano’s multistage functionality…

http://weblog.jamisbuck.org/2007/7/23/capistrano-multistage

Create a “staging” environment file, entry in database.yml, and anywhere else you have development/production stuff…

Then you can do

cap staging deploy # to heroku

cap production deploy # to ubuntu

Thanks. I had not really considered using cap to deploy to heroku but makes sense and will actually save me some manual work once I build out the cap file.

David Kahn wrote in post #961017:

> GitHub - binarylogic/settingslogic: A simple and straightforward settings solution that uses an ERB enabled YAML file and a singleton design pattern.

cap staging deploy # to heroku

cap production deploy # to ubuntu

Thanks. I had not really considered using cap to deploy to heroku but makes sense and will actually save me some manual work once I build out the cap file.

Why would you use Cap to deploy to Heroku? *How* would you even do that? By setting some environment variables and calling git push?

If that's all, then it's probably not necessary. Heroku has its own configuration interface for setting environment variables (and you could set RAILS_ENV if you wanted it to be "production_heroku" instead of "production").

Best,

David Kahn wrote in post #961017:

https://github.com/binarylogic/settingslogic

cap staging deploy # to heroku

cap production deploy # to ubuntu

Thanks. I had not really considered using cap to deploy to heroku but

makes

sense and will actually save me some manual work once I build out the

cap

file.

Why would you use Cap to deploy to Heroku? How would you even do

that? By setting some environment variables and calling git push?

If that’s all, then it’s probably not necessary. Heroku has its own

configuration interface for setting environment variables (and you could

set RAILS_ENV if you wanted it to be “production_heroku” instead of

“production”).

For one, my storage location is different - I use S3. This is probably the only major setting difference. Right now I manually change the variable, but that opens me up to not turning it off when I push to production. So you are saying I could create a new rails environment that is Heroku? Do you know offhand how I would tell heroku to use “production_heroku” rather than production? I thought it just automatically used “production” in all cases.

David Kahn wrote in post #961052:

>> If that's all, then it's probably not necessary. Heroku has its own configuration interface for setting environment variables (and you could set RAILS_ENV if you wanted it to be "production_heroku" instead of "production").

For one, my storage location is different - I use S3. This is probably the only major setting difference. Right now I manually change the variable, but that opens me up to not turning it off when I push to production.

No, in fact it doesn't. Heroku has a completely independent interface for setting config variables, so there's nothing to forget to turn off.

See http://docs.heroku.com/config-vars.

So you are saying I could create a new rails environment that is Heroku? Do you know offhand how I would tell heroku to use "production_heroku" rather than production? I thought it just automatically used "production" in all cases.

Rails always, always, always uses whatever environment RAILS_ENV tells it to use (or "development" if RAILS_ENV isn't set). So just set RAILS_ENV to something else.

Best,