Skip to content

Latest commit

 

History

History
39 lines (27 loc) · 2.48 KB

DEVELOPER_README.md

File metadata and controls

39 lines (27 loc) · 2.48 KB

Developer Notes

These notes are only of interest to developers maintaining this repository.

Unit Tests

Several of the unit tests do attempt to run the TestRunners against active Translator components. Such tests may occasionally fail due to changes in the target components, or may be much longer running. For both reasons, the FULL_TEST environment variable needs to be set to '1' (== 'True') to run all such tests (but has a default value of '0' == 'False'). This ensures that these 'exhaustive' tests are not attempted in CI (i.e. in GitHub Action) environments.

Maintaining Dependencies

This project uses the poetry dependency management tool to orchestrate its installation and dependencies. As such, new or revised Python module dependencies are curated within the pyproject.toml file.

For release step #5 below, you may need to install the 'export' poetry plug-in as follows:

poetry self add poetry-plugin-export

Then disable the plugin warning:

poetry config warnings.export false

Project Releases

Steps to properly issue a new project release:

  1. Run the unit test suite to ensure that nothing fails. Iterate to fix failures (in the code or in terms of revised unit tests to reflect fresh code designs)
  2. Document release changes in the CHANGELOG.md
  3. Update the [Tool Poetry]version = field in the pyprojects.yaml, e.g. "0.1.5"
  4. Run poetry update (preferably, within a poetry shell)
  5. The project pip requirements.txt file snapshot of dependencies should also be updated at this point (type $ poetry export --output requirements.txt, assuming that the proper poetry export plugin is installed). This may facilitate module deployment within environments that prefer to use pip rather than poetry to manage their deployments.
  6. Commit or pull request merge all files (including the poetry.lock file) to the local main branch.
  7. Add the equivalent Git tag to main. This should be the Semantic Version string from step 4 with an added 'v' prefix, e.g. "v0.1.4".
  8. Push main to remote.
  9. Check if Git Actions for testing and documentation complete successfully.
  10. Create a Git package release using the same release tag, e.g. "v0.1.4".
  11. Check if Git Actions for package deployment is successful and check if the new version (e.g. "v0.1.4") is now visible on pypy.org