Our production Heroku deployment is controlled by the following files:
Procfile
: tells Heroku what command to launch in each Dyno;runtime.txt
: tells Heroku which run-time engine to use (i.e., which version of Python);requirements.txt
: tells Heroku what our production dependencies are;bin/post_compile
: Heroku builds run this after doingpip install -r requirements.txt
.
Updating dependencies:
-
Our dependencies are declared in
pyproject.toml
. This is where changes should be made first. -
requirements.txt
is the generated "lock" file that Heroku uses. To update it, run these commands, preferably from a Linux machine to match the Heroku context:hatch env remove prod rm requirements.txt hatch env create prod
Then manually remove the soundswallower line, since it's not needed for the web api.
It is also possible to edit it manually, e.g., to handle a critical vulnerability report, but an occasional full rebuild is a good idea, to keep things up to date.
Updating g2p
:
- By default,
g2p
only gets updated forreadalong-studio
on Heroku when:- we make a new release of
g2p
on PyPI, and - we update
requirements.txt
here to ask for that release
- we make a new release of
- Manual override: it is also possible to update g2p to the current commit on the
main
branch using this procedure:- Change
requirements.txt
to specifyg2p @ git+https://github.com/roedoejet/g2p@main
. - Commit that change to
main
in a sandbox connected to Heroku. git push heroku main
- This will force a build which will fetch the main branch of g2p from GitHub.
- Subsequent builds reuse the cached g2p, so they'll reuse this one. Exception: if
runtime.txt
is updated, a fresh build is done and g2p will be reverted to the latest published version.
- Change