You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- harden palette plotting, respect confusion-matrix opts, and keep generator inputs working across plot helpers
- scope image colorbars to their axes, safeguard signal normalization/stable rank, and flush stopwatch timing output
- document updated behaviours, satisfy pyrefly typing, and broaden tests (including ridgeline color handling and ellipse coverage)
- Run `uv run ruff check .` before committing to ensure all Python code passes linting.
5
-
- Write clear docstrings for all public functions and classes.
6
-
- Use relative imports within the `jetplot` package.
3
+
## Project Structure & Module Organization
4
+
Source lives under `src/jetplot/`, split into focused modules such as `colors.py`, `plots.py`, and `style.py`. Add new utilities in cohesive files and keep imports relative (e.g. `from .colors import Palette`). Tests reside in `tests/` and should mirror the module layout; prefer descriptive folders like `tests/test_plots.py` to match the feature under test. Documentation content is maintained in `docs/` and rendered via MkDocs, while build artefacts land in `build/` and `dist/`.
7
5
8
-
## Testing
9
-
- Run `uv run pytest --cov=jetplot --cov-report=term` before committing to ensure all tests pass before submitting a PR.
10
-
- Run `uv run pyrefly check` before committing to ensure all pyrefly type checking passes.
6
+
## Build, Test, and Development Commands
7
+
Run `uv run ruff check .` to ensure linting passes and style expectations are met. Use `uv run pytest --cov=jetplot --cov-report=term` for the full suite with coverage feedback, and `uv run pyrefly check` to validate typing across the package. When iterating on documentation, launch `uv run mkdocs serve` for a live preview. Regenerate distributions with `uv build` once changes are ready to publish.
11
8
12
-
## PR Guidelines
13
-
- Your pull request description must contain a **Summary** section explaining the changes.
14
-
- Include a **Testing** section describing the commands used to run lint and tests along with their results.
9
+
## Coding Style & Naming Conventions
10
+
Follow PEP 8 defaults: four-space indentation, snake_case for functions and module-level variables, and CapWords for classes. Exported constants stay upper-case with underscores. Provide clear docstrings for every public function or class that describes inputs, return values, and side effects. Keep modules small, favor pure functions, and rely on the shared helpers already defined in `style.py` and `chart_utils.py` instead of duplicating logic.
11
+
12
+
## Testing Guidelines
13
+
Write pytest-based tests alongside new functionality, naming files `test_<feature>.py` and individual tests `test_<behavior>`. Prefer parametrization to cover edge cases concisely. Aim to maintain or raise the coverage reported by the standard coverage command; unexpected drops should block merges. Include regression tests when fixing bugs so future refactors stay guarded.
14
+
15
+
## Commit & Pull Request Guidelines
16
+
Commits use short, imperative summaries (e.g. `Add palette cycler helper`). Break large efforts into logical commits that pass linting and tests independently. Pull requests must include **Summary** and **Testing** sections outlining what changed and the exact commands run (`uv run ruff check .`, `uv run pytest --cov=jetplot --cov-report=term`, `uv run pyrefly check`). Link relevant issues and add screenshots when UI-facing artifacts such as documentation pages change.
17
+
18
+
## Documentation Tips
19
+
Reference existing examples in `docs/` when adding guides, and keep code snippets synced with the APIs under `src/jetplot/`. Rebuild the site locally with `uv run mkdocs serve` after edits to verify navigation, formatting, and cross-links before submitting your changes.
0 commit comments