|
| 1 | +# Contributing to Zerobus SDK for Python |
| 2 | + |
| 3 | +We happily welcome contributions to the Zerobus SDK for Python. We use [GitHub Issues](https://github.com/databricks/zerobus-sdk-py/issues) to track community reported issues and [GitHub Pull Requests](https://github.com/databricks/zerobus-sdk-py/pulls) for accepting changes. |
| 4 | + |
| 5 | +Contributions are licensed on a license-in/license-out basis. |
| 6 | + |
| 7 | +## Communication |
| 8 | + |
| 9 | +Before starting work on a major feature, please open a GitHub issue. We will make sure no one else is already working on it and that it is aligned with the goals of the project. |
| 10 | + |
| 11 | +A "major feature" is defined as any change that is > 100 LOC altered (not including tests), or changes any user-facing behavior. |
| 12 | + |
| 13 | +We will use the GitHub issue to discuss the feature and come to agreement. This is to prevent your time being wasted, as well as ours. The GitHub review process for major features is also important so that organizations with commit access can come to agreement on design. |
| 14 | + |
| 15 | +If it is appropriate to write a design document, the document must be hosted either in the GitHub tracking issue, or linked to from the issue and hosted in a world-readable location. |
| 16 | + |
| 17 | +Small patches and bug fixes don't need prior communication. |
| 18 | + |
| 19 | +## Development Setup |
| 20 | + |
| 21 | +### Prerequisites |
| 22 | + |
| 23 | +- Python 3.7 or higher |
| 24 | +- Git |
| 25 | +- pip |
| 26 | + |
| 27 | +### Setting Up Your Development Environment |
| 28 | + |
| 29 | +1. **Clone the repository:** |
| 30 | + ```bash |
| 31 | + git clone https://github.com/databricks/zerobus-sdk-py.git |
| 32 | + cd zerobus-sdk-py |
| 33 | + ``` |
| 34 | + |
| 35 | +2. **Create and activate a virtual environment:** |
| 36 | + ```bash |
| 37 | + make dev |
| 38 | + ``` |
| 39 | + |
| 40 | + This will: |
| 41 | + - Create a virtual environment in `.venv` |
| 42 | + - Install the package in development mode with all dev dependencies |
| 43 | + |
| 44 | +3. **Activate the virtual environment:** |
| 45 | + ```bash |
| 46 | + source .venv/bin/activate # On Windows: .venv\Scripts\activate |
| 47 | + ``` |
| 48 | + |
| 49 | +## Coding Style |
| 50 | + |
| 51 | +Code style is enforced by a formatter check in your pull request. We use [Black](https://github.com/psf/black) to format our code. Run `make fmt` to ensure your code is properly formatted prior to raising a pull request. |
| 52 | + |
| 53 | +### Running the Formatter |
| 54 | + |
| 55 | +Format your code before committing: |
| 56 | + |
| 57 | +```bash |
| 58 | +make fmt |
| 59 | +``` |
| 60 | + |
| 61 | +This runs: |
| 62 | +- **Black**: Code formatting |
| 63 | +- **autoflake**: Remove unused imports |
| 64 | +- **isort**: Sort imports |
| 65 | + |
| 66 | +### Running Linters |
| 67 | + |
| 68 | +Check your code for issues: |
| 69 | + |
| 70 | +```bash |
| 71 | +make lint |
| 72 | +``` |
| 73 | + |
| 74 | +This runs: |
| 75 | +- **pycodestyle**: Style guide enforcement |
| 76 | +- **autoflake**: Check for unused imports |
| 77 | + |
| 78 | +## Pull Request Process |
| 79 | + |
| 80 | +1. **Create a feature branch:** |
| 81 | + ```bash |
| 82 | + git checkout -b feature/your-feature-name |
| 83 | + ``` |
| 84 | + |
| 85 | +2. **Make your changes:** |
| 86 | + - Write clear, concise commit messages |
| 87 | + - Follow existing code style |
| 88 | + - Update documentation as needed |
| 89 | + |
| 90 | +3. **Format your code:** |
| 91 | + ```bash |
| 92 | + make fmt |
| 93 | + ``` |
| 94 | + |
| 95 | +4. **Commit your changes:** |
| 96 | + ```bash |
| 97 | + git add . |
| 98 | + git commit -m "Add feature: description of your changes" |
| 99 | + ``` |
| 100 | + |
| 101 | +5. **Push to your fork:** |
| 102 | + ```bash |
| 103 | + git push origin feature/your-feature-name |
| 104 | + ``` |
| 105 | + |
| 106 | +6. **Create a Pull Request:** |
| 107 | + - Provide a clear description of changes |
| 108 | + - Reference any related issues |
| 109 | + - Ensure all CI checks pass |
| 110 | + |
| 111 | +## Signed Commits |
| 112 | + |
| 113 | +This repo requires all contributors to sign their commits. To configure this, you can follow [Github's documentation](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) to create a GPG key, upload it to your Github account, and configure your git client to sign commits. |
| 114 | + |
| 115 | +## Developer Certificate of Origin |
| 116 | + |
| 117 | +To contribute to this repository, you must sign off your commits to certify that you have the right to contribute the code and that it complies with the open source license. The rules are pretty simple, if you can certify the content of [DCO](./DCO), then simply add a "Signed-off-by" line to your commit message to certify your compliance. Please use your real name as pseudonymous/anonymous contributions are not accepted. |
| 118 | + |
| 119 | +``` |
| 120 | +Signed-off-by: Joe Smith <[email protected]> |
| 121 | +``` |
| 122 | + |
| 123 | +If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`: |
| 124 | + |
| 125 | +```bash |
| 126 | +git commit -s -m "Your commit message" |
| 127 | +``` |
| 128 | + |
| 129 | +## Code Review Guidelines |
| 130 | + |
| 131 | +When reviewing code: |
| 132 | + |
| 133 | +- Check for adherence to code style |
| 134 | +- Look for potential edge cases |
| 135 | +- Consider performance implications |
| 136 | +- Ensure documentation is updated |
| 137 | + |
| 138 | +## Commit Message Guidelines |
| 139 | + |
| 140 | +Follow these conventions for commit messages: |
| 141 | + |
| 142 | +- Use present tense: "Add feature" not "Added feature" |
| 143 | +- Use imperative mood: "Fix bug" not "Fixes bug" |
| 144 | +- First line should be 50 characters or less |
| 145 | +- Reference issues: "Fix #123: Description of fix" |
| 146 | + |
| 147 | +Example: |
| 148 | +``` |
| 149 | +Add async stream creation example |
| 150 | +
|
| 151 | +- Add async_example.py demonstrating non-blocking ingestion |
| 152 | +- Update README with async API documentation |
| 153 | +
|
| 154 | +Fixes #42 |
| 155 | +``` |
| 156 | + |
| 157 | +## Documentation |
| 158 | + |
| 159 | +### Updating Documentation |
| 160 | + |
| 161 | +- Update docstrings for all public APIs |
| 162 | +- Use Google-style docstrings |
| 163 | +- Include examples in docstrings where helpful |
| 164 | +- Update README.md for user-facing changes |
| 165 | +- Update examples/ for new features |
| 166 | + |
| 167 | +Example docstring: |
| 168 | +```python |
| 169 | +def ingest_record(self, record) -> RecordAcknowledgment: |
| 170 | + """ |
| 171 | + Submits a single record for ingestion into the stream. |
| 172 | +
|
| 173 | + This method may block if the maximum number of in-flight records |
| 174 | + has been reached. |
| 175 | +
|
| 176 | + Args: |
| 177 | + record: The Protobuf message object to be ingested. |
| 178 | +
|
| 179 | + Returns: |
| 180 | + RecordAcknowledgment: An object to wait on for the server's acknowledgment. |
| 181 | +
|
| 182 | + Raises: |
| 183 | + ZerobusException: If the stream is not in a valid state for ingestion. |
| 184 | +
|
| 185 | + Example: |
| 186 | + >>> record = AirQuality(device_name="sensor-1", temp=25) |
| 187 | + >>> ack = stream.ingest_record(record) |
| 188 | + >>> ack.wait_for_ack() |
| 189 | + """ |
| 190 | +``` |
| 191 | + |
| 192 | +## Continuous Integration |
| 193 | + |
| 194 | +All pull requests must pass CI checks: |
| 195 | + |
| 196 | +- **fmt**: Runs formatting checks (black, autoflake, isort) |
| 197 | + |
| 198 | +The formatting check runs `make dev fmt` and then checks for any git differences. If there are differences, the check will fail. |
| 199 | + |
| 200 | +You can view CI results in the GitHub Actions tab of the pull request. |
| 201 | + |
| 202 | +## Makefile Targets |
| 203 | + |
| 204 | +Available make targets: |
| 205 | + |
| 206 | +- `make dev` - Set up development environment |
| 207 | +- `make install` - Install package |
| 208 | +- `make build` - Build wheel package |
| 209 | +- `make fmt` - Format code with black, autoflake, and isort |
| 210 | +- `make lint` - Run linting with pycodestyle |
| 211 | +- `make clean` - Remove build artifacts |
| 212 | +- `make help` - Show available targets |
| 213 | + |
| 214 | +## Versioning |
| 215 | + |
| 216 | +We follow [Semantic Versioning](https://semver.org/): |
| 217 | + |
| 218 | +- **MAJOR**: Incompatible API changes |
| 219 | +- **MINOR**: Backwards-compatible functionality additions |
| 220 | +- **PATCH**: Backwards-compatible bug fixes |
| 221 | + |
| 222 | +## Getting Help |
| 223 | + |
| 224 | +- **Issues**: Open an issue on GitHub for bugs or feature requests |
| 225 | +- **Discussions**: Use GitHub Discussions for questions |
| 226 | +- **Documentation**: Check the README and examples/ |
| 227 | + |
| 228 | +## Package Name |
| 229 | + |
| 230 | +The package is published on PyPI as `databricks-zerobus-ingest-sdk`. |
| 231 | + |
| 232 | +## Code of Conduct |
| 233 | + |
| 234 | +- Be respectful and inclusive |
| 235 | +- Welcome newcomers |
| 236 | +- Focus on constructive feedback |
| 237 | +- Follow the [Python Community Code of Conduct](https://www.python.org/psf/conduct/) |
0 commit comments