Learn the coding conventions contributors to Pachyderm's code base follow.
December 5, 2022
Interested in contributing to Pachyderm’s code? Learn the conventions here! For setup instructions, see Setup for Contributors.
The Pachyderm repository is written using Go, Shell, and Make. Exceptions to this are:
/examples: For showcasing how to use the product in various languages.
/doc: For building documentation using a python-based static site generator (MkDocs).
See the Effective Go Style Guide for standard conventions.
- Consider the package name when naming an interface to avoid redundancy. For example,
storage.Interfaceis better than
- Do not use uppercase characters, underscores, or dashes in package names.
package fooline should match the name of the directory in which the
- Importers can use a different name if they need to disambiguate.
- When multiple locks are present, give each lock a distinct name following Go conventions (e.g.,
Go Modules/Third-Party Code #
- See the Go Modules Usage and Troubleshooting Guide for managing Go modules.
- Go dependencies are managed with go modules.
go get footo add or update a package; for more specific versions, use
go get email@example.com,
go get foo@master, or
go get foo@e3702bed2.
- See the Helm Best Practices guide series.
- See the Go Code Review Comments guide for a list of common comments.
- See the Go Test Comments guide for a list of common test code comments.
- Make sure CI is passing for your branch.
- Run checks using
- All packages and significant functionality must come with test coverage.
- Local unit tests should pass before pushing to GitHub (
make integration-testsfor integrations).
- Use short flag for local tests only.
- Avoid waiting for asynchronous things to happen; If possible, use a method of waiting directly (e.g. ‘flush commit’ is much better than repeatedly trying to read from a commit).
- Run single tests or tests from a single package; the Go tool only supports tests that match a regular expression (for example,
go test -v ./src/path/to/package -run ^TestMyTest).
- When writing documentation, follow the Style Guide conventions.
- PRs that have only documentation changes, such as typos, is a great place to start and we welcome your help!