Chalice: Should `chalice local` set environment variables?

[wollerman]

When running chalice local, currently it doesn't read .chalice/config.json and set the appropriate environment variables. I can argue either way:

• Against: Don't set them because this should be something handled by the environment and part of test setup.
• For: When deploying chalice takes care of this and sets them appropriately. So to correctly mimic this functionality locally, chalice should set the appropriate environment variables. Also, because chalice provides stages, these variables are most likely already specified appropriately.

Maybe an added command line flag would solve this: --set-env-from-config.

What do others think?

Thanks!

[JordonPhillips]

Good idea! I definitely think we should do it. Marking as a feature request.

[wollerman]

So actually, not getting environment variables was only anecdotal. I decided to check the CLI source to see how it's currently handled (and maybe add a PR). It looks like it should be set: https://github.com/aws/chalice/blob/master/chalice/cli/__init__.py#L92-L95

This feature request might be redundant unless people want the ability to control turning off loading from the config. I'm going to try a few things locally to verify. But env.update(config.environment_variables) seems like exactly what I was looking for.

Not sure why it wasn't working for me though. Maybe this will turn into a bug report.

[wollerman]

Digging in I've found that it's because of my exception handling when not providing an environment variable. When the configs are loaded, the app is also generated: https://github.com/aws/chalice/blob/master/chalice/cli/factory.py#L108

However, I throw an exception when my environment variables aren't set. Which means right before the app loading point, I can see the variables are loaded correctly: https://github.com/aws/chalice/blob/master/chalice/cli/factory.py#L99

Why is the app loaded to be set as a parameter on the config?
https://github.com/aws/chalice/blob/master/chalice/cli/factory.py#L109

Thanks!

[wollerman]

@JordonPhillips I couldn't seem to find why the user param chalice_app is being setup in the config loading. If this isn't necessary then perhaps this should be changed to a bug report?

[JordonPhillips]

@wollerman chalice_app is loaded because Chalice needs to read your code in order to support its various features. It's how we're able to look through all your @app.route declarations, for instance. What we should do is setup the environment when we make the import call.

I'm going to go ahead and open up an issue for that.

[JordonPhillips]

@wollerman does #584 accurately capture your issue? I tried to cover data from a few issues, let me know if there's anything I missed.

[wollerman]

@JordonPhillips agreed the environment should be setup before the module level code is executed. Yea that issue directly addresses it.

Thanks for the quick response and efforts!

[jpeters71]

If I understand the issue correctly, if you want to read from the config.json file when running locally, you need to specify the '--stage ' flag. This will pull in env vars for whatever stage you specified. For example, we have a "local" stage with local specific env vars. So when we run it we use:
chalice local --stage local

...and it pulls in the right values.

Does that help you at all?

[wollerman]

@jpeters71: Correct, the stage flag does pull in values. However, the issue is a chicken/egg problem. Chalice loads the app to support features at time of environment variable loading. So if you want to have a line that checks for environment variables being set, this code is run before the environment variables are set. A simple example would be:

from chalice import Chalice
import os

app = Chalice(app_name='demo')

if os.getenv('SUPER_SPECIAL', False):
  raise EnvironmentError('SUPER_SPECIAL must be set before anything else!')

@app.route('/')
def index():
    return {'hello': 'world'}

In this case, even with SUPER_SPECIAL being set in the config.json, chalice will raise the EnvironmentError because module level code is run before the environment is completely setup.

[jpeters71]

Sorry, I misunderstood the issue. We were bitten by this one too and had to come up with workarounds (none very ideal).

[JordonPhillips]

Excellent, glad it's all clear! I'm gonna go ahead and close out this issue in favor of #584. Thanks again for reporting and helping me to understand your issue! If you have any other problems, feel free to open a new issue.