Skip to content

Commit 3ae9302

Browse files
Add cursor rules file and update contributing documentation
Co-Authored-By: Aaron <AJ> Steers <[email protected]>
1 parent 9ad9e09 commit 3ae9302

File tree

2 files changed

+63
-0
lines changed

2 files changed

+63
-0
lines changed

.cursorrules

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
Here are some notes for Python CDK development.
2+
3+
## Development Setup
4+
5+
* Use Poetry for dependency management
6+
- Install dependencies with `poetry install --all-extras`
7+
- Run commands with `poetry run` or activate the virtual environment
8+
- Use Poe tasks for common operations: `poetry run poe list`
9+
10+
## Testing
11+
12+
* Write unit tests in the `unit_tests` directory
13+
- Tests should follow the same directory structure as the code they test
14+
- Use pytest fixtures for common test setup
15+
- Run tests with `poetry run poe pytest` or `poetry run poe pytest-fast` for faster tests
16+
17+
## Linting and Formatting
18+
19+
* Use Ruff for linting and formatting
20+
- Run `poetry run poe format-fix` to auto-fix formatting issues
21+
- Run `poetry run poe lint` to check for linting issues
22+
- Run `poetry run poe check-all` to run all checks
23+
24+
## Code Organization
25+
26+
* Follow the existing module structure
27+
- Place new code in the appropriate module based on functionality
28+
- Use relative imports within modules
29+
- Avoid circular dependencies by careful import ordering
30+
31+
## Import Conventions
32+
33+
* Avoid circular dependencies by following these guidelines:
34+
- Submodules should import from lower-level modules, not from the top-level `airbyte_cdk` package
35+
- Use `if TYPE_CHECKING:` blocks for imports that are only used as type hints
36+
- For modules with circular dependency risks, use explicit relative imports
37+
38+
* Special handling for `__init__.py` files:
39+
- Do not auto-sort imports in `__init__.py` files with isort
40+
- When a module depends on classes defined within the same module, use the isort split directive:
41+
```python
42+
# Import the base class first
43+
from .transformation import RecordTransformation
44+
45+
# isort: split
46+
# Then import the implementations
47+
from .add_fields import AddFields
48+
from .remove_fields import RemoveFields
49+
```
50+
51+
## Docstring Standards
52+
53+
* Use Google-style docstrings
54+
- First sentence must be a one-liner on the same line as opening `"""` and end with a period
55+
- Multi-line docstrings require a blank line after the one-liner
56+
- Args section is optional, but if "args:" is specified, all arguments must be documented
57+
- Argument types should not be documented in docstrings as they are already in function signatures

docs/CONTRIBUTING.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -90,6 +90,12 @@ Only Airbyte CDK maintainers can run slash commands. The most common slash comma
9090
The full list of available slash commands can be found in the [slash command dispatch file](https://github.com/airbytehq/airbyte-python-cdk/blob/main/.github/workflows/slash_command_dispatch.yml#L21-L25).
9191

9292
# Appendix: Advanced Topics
93+
## Development Guidelines and Cursor Rules
94+
95+
The Airbyte Python CDK uses specific development guidelines to maintain consistent code organization and avoid common issues. These guidelines are documented in the [.cursorrules](./../.cursorrules) file at the root of the repository.
96+
97+
When working with the CDK codebase, please review the cursor rules to ensure your changes follow the project's development practices, especially regarding import conventions, docstring standards, and code organization.
98+
9399

94100
## Using MockServer in Place of Direct API Access
95101

0 commit comments

Comments
 (0)