on both client and server. Even if I’m not getting the expected result, it seems that meteor is looking at this variable because if I’ve a typo, for instance:
in function _computeEnvironment line 242 it deletes env.METEOR_SETTINGS. Commenting out that one line and Meteor.settings and process.env.METEOR_SETTINGS are back.
Problem is I compared the following versions and run-app.js is the same when it comes to _computeEnvironment. I just created a small project with 1.3.4_1 and METEOR_SETTINGS environment also does not exist (because it gets deleted in run-app.js)
Well, the logic is that it’s working as documented.
From the docs you linked to above, it doesn’t say you can use METEOR_SETTINGS in development:
Meteor.settings contains deployment-specific configuration options. You can initialize settings by passing the --settings option (which takes the name of a file containing JSON data) to meteor run or meteor deploy. When running your server directly (e.g. from a bundle), you instead specify settings by putting the JSON directly into the METEOR_SETTINGS environment variable.
So, in other words: in development (meteor run is the same as meteor), you need to use --settings file.json and in production (a bundle) you need to use METEOR_SETTINGS.
This is to allow reactivity in development. Changes to environment variables cannot be detected (nor could you actually change them unless you were the process itself), but a change to settings.json can be detected when the file is changed (i.e. when you save the file in your editor).
It’s not really clear to me how an environment variable would be more flexible. If you have the settings, just write them to the settings file and they will get picked up automatically:
$ # Write first setttings...
$ echo '{"public":{"SERVER_CONFIG":"test"},"server":1}' > settings.json
$ meteor --settings settings.json # Start Server
$ echo '{"public":{"SERVER_CONFIG":"new_settings!"},"server":9000}' > settings.json
$ # Settings picked up by server automatically.
Thanks for the response. I’ve different environment configs I want to put in Meteor settings and it’s easier to modify (at least for me) an environment variable I can create from javascript as a json, than it is to generate a file every time. Plus that would not change from what I’ve to do for my production deployement
Can you elaborate? It’s still not clear to me why you couldn’t just write what you have to a file.
Realistically, it’s not hard to change the way the meteor-tool works to support METEOR_SETTINGS environment variable – but as I stated above the reactivity would be affected and I’d be afraid that some users wouldn’t realize this and would spend time trying to change environment variables dynamically (most likely problematic) when a much easier mechanism is already in place.
I’m relatively sure there’s a solution to your issue that doesn’t involve using METEOR_SETTINGS. The development environment is so much more dynamic than the production environment. You could easily write that settings.json file out from an environment variable, using node, or any number of ways.
For example, if you’ve already got it in a METEOR_SETTINGS environment variable, you could just do the following when you start your app:
You’re right. I take back what I said. I’ve done something like mup does with the mup.js config file that creates env var from a javascript code and I was somewhat reluctant to have to use a file to pass those variables. But I’ll just ignore the file from git and do
