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?

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

On Fri, Nov 12, 2010 at 9:51 AM, Philip H. [email protected]
wrote:

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…

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

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…

On Nov 12, 2010, at 8:27 AM, Philip H. wrote:

Buckblog: 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

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.

On Fri, Nov 12, 2010 at 10:27 AM, Philip H. [email protected]
wrote:

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.

David K. wrote in post #961017:

On Fri, Nov 12, 2010 at 10:27 AM, Philip H. [email protected]
wrote:

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On Fri, Nov 12, 2010 at 11:45 AM, Marnen Laibow-Koser
[email protected]wrote:

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.

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…

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

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

David K. wrote in post #961052:

On Fri, Nov 12, 2010 at 11:45 AM, Marnen Laibow-Koser
[email protected]wrote:

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 Configuration and Config Vars | Heroku Dev Center.

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]