Packaging

Key Points

Environments	Virtual environments isolate software Virtual environments solve the update problem
Code to Package	Put your code and tests in a standard package structure Use a `pyproject.toml` file to describe a Python package
Other files that belong with your package	Packages should include a README, LICENSE, and CHANGELOG. Choose an existing software license You can also include `.gitignore` to avoid from committing non-source files.
Metadata	Add informational metadata to tell people about your package. Add functional metadata to tell people how to install and use your package.
Versioning	Packages should have a version attribute Semantic versioning is an abbreviated changelog, not the solution to all problems You can use packaging tools so that the version number needs updating in one (and only one) place
Publishing package and citation	CI can publish Python packages Tagging and GitHub Releases are used to publish versions Zenodo and CITATION.cff are useful for citations
Documentation Overview	Sphinx or MkDocs are both good for documentation
Documentation with Sphinx	Sphinx is great for documentation
Documentation with MkDocs Material	MkDocs is great for documentation
Checks and tests	Run tests and static checks on your codebase.
Task runners	A task runner makes it easier to contribute to software
Continuous Integration	Set up GitHub Actions on your project Run your tests on multiple platforms and with multiple Python versions