On Linux and OS X, I'm accustomed to running Rake tasks in specified Rails "environments" by doing this:
$ export RAILS_ENV=monster_island ; rake monsters:destroy_all
How can I do the equivalent if I'm running the task on Windows XP in a Windows console?
c:>set RAILS_ENV=monster_island
If you run set without any other arguments, you will see the environment variables that are set. Running set in a console will set that variable for just that console and won't be persisted across sessions or to other consoles.
You can also set it permanently in the Control Panel - open System, select Advanced, and then Environment Variables (this may vary slightly depending on your version of Windows).
Of course you can use 'setX' (instead of simply 'set' if you want the variable to persist between console sessions (and you don't want to navigate through the various screens/tabs in the Control Panel
Related
I was reading from this article that you can create a config/local_env.yml with environment variables and then use config/application.rb to read it to replace/take priority before the environment variables that you export in your .bashrc. What then is the .env used for then? Does it serve the same purpose as the config/local_env.yml?
All of these methods are used to feed environment variables to your rails application. So, from an app's point of view, it serves the same purpose whether you export it from .env or .bashrc or config/local_env.yml files.
The differences in these methods are really a matter of personal choice among the team members involved in maintaining the app's development and deployment environments. However, here are few things to consider while opting for either of these choices.
.bashrc - Use this if you manually configure deployment servers and really comfortable with linux/unix command line system administration. This configuration file is specific to bash shell (Bourne Again Shell). You need to configure different file if your server uses different shell (for example: .zshrc if it uses Z Shell)
.env - Use this if you want to keep your app centric environment variables within the app itself while maintaining different variations of environment variables for different runtime environments of your rails app. For example: .env.development and .env.test files with specific values of the environment variables for your development and test environments respectively. This gives you more control of your app's environment variables and do not have to rely on the platform (terminal shell) you want to deploy your app.
config/local_env.yml - This is similar to .env approach, which is provided out of the box by rails gem that allows you to configure environment variables for your app in yml format. This method also keeps your app's configuration within the app irrespective of the shell you are using to run your app.
In addition to the previous answer, another downside of using .bashrc is that it is specific to only one user, so if you're e.g. starting your app server as a systemd service then I believe it won't see your variables.
Meanwhile, .env's Github readme says that it is not the most recommended thing to use outside of the development environment, although it is OK for that purpose.
Another two options to consider are:
Rails secrets. The benefit of this approach is that you get to commit it to git since it's encrypted, so when working in a team you will all have access to the same file. The downside is that it is coupled to the RAILS_ENV variable, so you can't use it to set that e.g. to production on your production app (but you can manually pass it every time it's invoked). Another downside is that if you have a staging environment, then apparently Heroku discourages using RAILS_ENV=staging, which you sometimes really need, so if you need it then you can either do it anyway, or you'll need to set the differing variables via a different mechanism - for example my app has a variable which points to the URL of another part of my app, this URL needs to point to its staging variant on staging, and to its production variant on production, so it needs to differ between my production and staging environment.
Using an /etc/environment file - note that systemd services don't have access to it by default so you'd have to add the line EnvironmentFile=/etc/environment. Also if you're running a shell script from a non-login shell (which happens sometimes), they it won't load them either, but the solution is to just include in your script this: set -a; source /etc/environment; set +a. You should be careful not to commit this to git. If you're working in a team and you need to manage this file then it gets a little complicated since it's not committed to git, but maybe there's a way to have it encrypted. (systemd services note: you might optionally use LoadCredential= for sensitive variables such as private keys, so that other processes won't have access to them; if you do this then you can also commit to git /etc/environment which should now contain non-sensitive variables only).
In my opinion both of those are valid and it's fine to pick whatever is easier to do in your app.
I am trying to debug a problem with secrets.yml loading environment variables, by setting some environment variables in development and running rails c to inspect things. When I load Rails.applications.secrets this way, it is not picking up any of the environment variables I have set (namely, SECRET_KEY_BASE)
If I run the application with the same environment variables set, it picks them up fine (I'm using RubyMine to run the application, but running rails c from the terminal)
In my rails console, I can see the environment variable I've set using ENV['SECRET_KEY_BASE'], but it doesn't show up in Rails.application.secrets. Why?
TL;DR: spring stop
It turns out, as has happened so many times when things aren't making any sense, Spring is the culprit! I solved this problem (thanks to a related discussion) by running spring stop and then trying again, after which it worked perfectly!
Apparently Spring was caching the environment, or certain pieces of the Rails application, and neglecting to reload them when the environment variables changed.
How can I make my rails app aware of the new environment variables after I have edited my /etc/environment file on my remote EC2 instance?
I frequently add new (minor) things in my secrets.yml but I don't want to restart my server for it, nor do I want to use an existing secret.
In linux every process inherits envvars from its parent process and the values are passed by value, not by reference. Also, they don't behave like closures. So, child process (your rails/ruby app process) will not get any new environment variables of its parent (the shell process where you started your rails/ruby app).
That's why it is not possible. However, you can use gems like dotenv and figaro to watch some file with your environment variables and reload them when they are changed.
You should be able to add a line to your config/spring.rb:
Spring.watch "config/secrets.yml"
This will allow Spring to detect when changes have occurred in your secrets.yml file.
However, if you're actually asking about how to make your app aware that you've changed environment variables in a file, then it's not possible. Config values may be detected in files, but environment variables are detected in the shell environment. You have to load those into your shell for them to take any effect, and this would require stopping your server, sourcing the new changes into the environment, and starting the server again.
Understanding the difference between a config value in a file (.yml, .xml, .ini, etc) versus an environment variable in a shell script is important, because how it's applied and made usable is entirely different.
I need to make an environmental variable available to Sublime Text (3).
Specifically, I am using Ruby Test to run RSpec tests on a Rails app. In order for my Rails App to use Postgres it needs access to an env that I'm setting in my .bash_profile:
# Postgres
export PGHOST=localhost
If I launch ST from the Terminal, this env is available because my .bash_profileis loaded when I open the shell, however if I open ST by launching the app via its icon or via Alfred, .bash_profile is never loaded and this env is not available to ST, causing all my RSpec tests to fail due to problems connecting to the Postgres database.
So how can I pass environmental variables into Sublime Text (3)?
Just a guess, but if you are using the build system, perhaps adding the "shell": true option? If it's a plugin you are working through, perhaps create an issue for the plugin (I'm guessing it's on github)
In RubyMine the PATH when running rake tasks, for example, never contains /usr/local/bin, which I need because git is in there.
Is there a rubyMine-wide config of PATH, so I don't have to modify each target?
Set your environment variables in ~/.MacOSX/environment.plist or use the Environment Variables Preference Pane and they will apply to all of your applications. See Tip: How to setup Environment variables for RubyMine on Mac OS X
for more information.
RubyMine does not currently have an app-wide PATH setting.
In Mountain Lion there is no longer any reliable way to set the environment like there was using Environment Variables Preference Pane or ~/.MacOSX/environment.plist.
The easiest way to get the same environment in RubyMine as you have in the terminal is to launch RubyMine from Terminal with this:
open -a /Applications/RubyMine.app/