changes to enable module use #787
Conversation
server/api/src/settings.py
Outdated
| @@ -10,8 +11,8 @@ class Version: | |||
|
|
|||
|
|
|||
| class Server: | |||
| HOST = '0.0.0.0' | |||
| PORT = env('PORT', to.INT) | |||
| HOST = os.getenv('HOST', '0.0.0.0') | |||
There was a problem hiding this comment.
Can we do HOST = env('HOST') here, and then add HOST=0.0.0.0 before PORT in the .env.example file? And also remove import os from the top of this file.
I've found default environment variables to be convenient but ultimately counterproductive. If we're explicit about everything we expect the environment to to define -- rather than relying on defaults -- then it's easier to manage the production environment. You can just check the .env file to figure out what's happening instead of digging around in code.
There was a problem hiding this comment.
i didn't need the casting logic so was using the getenv approach, but makes sense to be consitent.
There was a problem hiding this comment.
Thanks! I'm just adding a tiny commit moving the host default (0.0.0.0) into the .env.example file
server/api/src/settings.py
Outdated
| HOST = '0.0.0.0' | ||
| PORT = env('PORT', to.INT) | ||
| HOST = os.getenv('HOST', '0.0.0.0') | ||
| PORT = env('PORT', to.INT, ) |
There was a problem hiding this comment.
is that second comma necessary?
There was a problem hiding this comment.
must've added that accidentally!
|
addressing PR comments. thanks for the feedback! |
So this change is to allow the API to be called as a module IN ADDITION to being run from bin/api_start. This means I don't need to use Docker to run the API. With this change I can debug the API locally (only running Postgres in Docker). I have some vscode settings files and a local dev.env file that sets PYTHONPATH to make this all work (VS Code is a little fiddly) which I can include in a future commit if other devs use VS Code.
I also included a baseline pipfile and pipfile.lock. I use pipenv for my projects. I've had good luck with it in the past, but would be happy to try poetry too. It might be good to standardize on some package management tool.
None of these changes should impact the current build process at all.
I didn't have an issue for these changes, so just included 'feat' in the branch name.
devbranchAny questions? See the getting started guide