Development¶
Get Started!¶
Check out code from the birdy GitHub repo and start the installation:
$ git clone https://github.com/bird-house/birdy.git
$ cd birdy
$ conda env create -f environment.yml
$ pip install --editable .
Install additional dependencies:
$ pip install -r requirements_dev.txt
When you’re done making changes, check that your changes pass black, flake8 and the tests:
$ black birdy tests
$ flake8 birdy tests
$ pytest -v tests
Or use the Makefile:
$ make lint
$ make test
$ make test-all
Add pre-commit hooks¶
Before committing your changes, we ask that you install pre-commit in your environment. Pre-commit runs git hooks that ensure that your code resembles that of the project and catches and corrects any small errors or inconsistencies when you git commit:
$ conda install -c conda-forge pre-commit
$ pre-commit install
Write Documentation¶
You can find the documentation in the docs/source folder. To generate the Sphinx documentation locally you can use the Makefile:
$ make docs
Bump a new version¶
Make a new version of Birdy in the following steps:
Make sure everything is commit to GitHub.
Update
CHANGES.rst
with the next version.Dry Run:
bumpversion --dry-run --verbose --new-version 0.3.1 patch
Do it:
bumpversion --new-version 0.3.1 patch
… or:
bumpversion --new-version 0.4.0 minor
Push it:
git push --tags
See the bumpversion documentation for details.
Release a new version¶
Leveraging GitHub Workflows, maintainers can release new versions of Birdy automatically:
Ensure that the changelog and version on the main development branch have been updated to reflect the new version.
- Create a tag (vX.Y.Z) of the main development branch and push to the GitHub repository.
This will trigger a workflow that will attempt to build Birdy and publish it to TestPyPI.
When this actions succeeds, be sure to verify on TestPyPI that the package reflects changes.
- On GitHub, a maintainer can then publish a new version using the newly created tag.
This will trigger a workflow that will attempt to build Birdy and publish it to PyPI.
Be warned that once published to PyPI, a version number can never be overwritten! Bad versions may only be yanked.