A collection of Python packages for use in the Alliance Platform Django template.
The project is structured as a monorepo, with each package in the packages
directory. As a convention, each package
in here is named ap-<name>
; this was chosen so it's not a valid python package name and is distinct from the underlying
package for ease of navigation / searching.
Each package has a namespaced package called alliance_platform
, and
then within that the specific package name (e.g. frontend
or codegen
). This allows all Alliance Platform packages
to be imported from alliance_platform
while being released and versioned independently.
- You will need to have PDM installed to manage the dependencies for this project.
brew install pdm
-
Run
pdm install
; this should create a virtual environment and install the dependencies. -
Run
yarn
; this will setup git hooks and is required for some tests inalliance-platform-frontend
, and is also used for change release management via changesets (see release process below).
NOTE: Currently, a single virtual env is used for all packages. See this issue.
This is handled by ruff
, and should automatically be run on commit. You can run it manually:
pdm run ruff check
pdm run ruff check --fix
pdm run ruff format
You can run pdm test
to run the tests for all packages.
You can run pdm mypy
to run the type checking for all packages.
You can run pdm build-docs-watch
to build the documentation for all packages, serve it locally, and watch for changes.
When a change is made that requires a release the following workflow applies:
- Run
yarn changeset
. Select the packages that have changed and the type of change (major, minor, patch). Add a description of the change. - This will create a new changeset file in the
.changeset
directory. You can modify this file if needed to adjust the description. - Commit the changeset file and open a pull request.
- Once the PR is merged, a GitHub action will automatically create a PR to bump the version and publish the package to PyPI. If such a PR exists already, it will be updated with the new changeset.
- When that PR is merged, the package will be published to PyPI.
To add a new package, create a directory in packages/
named ap-<name>
. It should contain a pyproject.toml
file and
a package.json
file; base these off the existing packages.
- Create a
pyproject.toml file
. This is relatively straightforward, but you can base it off the existing packages. - Create a
package.json
file. This is only required so thatchangesets
knows a package exists to be versioned, and to store the version number. You just need to set thename
here and choose the initialversion
. - Create the structure of the package like other packages; a namespaced
alliance_platform
package, and then the specific package name (e.g.frontend
orcodegen
). - Create a test app for the project, you can see
ap-frontend/test_alliance_platform_frontend
for an example. - Create a
manage.py
file based on an existing package, and update"DJANGO_SETTINGS_MODULE"
. - In GitHub a new token for publishing will be needed. It should be added to the release environment secrets
as
ALLIANCE_PLATFORM_<upper case package name>_TOKEN
. To create the token, go to PyPI and create a new token. The scope should be for the specific package only - if the package hasn't been published yet you can create one for all packages but you must re-create it after the initial publish and limit it to the specific package scope. Note that the PyPi Trusted Publishers would be good for this but I couldn't work out how to re-purpose it for our publishing workflow.- Update
.github/workflows/release.yml
and add the token under theenv
for theCreate Release Pull Request or Publish to pypi
step.
- Update
- Create a
docs
dir, see existing package for an example.- Create an entry in
docs/conf.py
undermultiproject_projects
for the new package. - In readthedocs.org, a new project needs to be created. To do this, import the https://github.com/AllianceSoftware/alliance-platform-py repo
again, but name it according to the package name (
alliance-platform-<name>
). - Under the new project, go to Settings and Environment Variables. Add a new variable
PROJECT
and name it the same as what the key inmultiple_projects
is. - Go to Automation Rules and add a rule for detecting version tags. Set it to a custom match on tags with the pattern
alliance-platform-NAME@\d\.\d\.\d
(where NAME is replaced with the package name) - Under settings check the
Build pull requests for this project:
option - Then, under the main
alliance-platform
settings you can add it as a subproject.
- Create an entry in