|
1 | | -# GitHub Copilot Custom Instructions for Cachier |
| 1 | +# Copilot Instructions for Cachier |
2 | 2 |
|
3 | | -- Cachier is a Python package providing persistent, stale-free memoization decorators for Python functions, supporting local (pickle), cross-machine (MongoDB), and in-memory caching backends. |
4 | | -- Always refer to the main decorator as `@cachier`, and note that it can be configured via parameters such as `stale_after`, `backend`, `mongetter`, `cache_dir`, `pickle_reload`, `separate_files`, `wait_for_calc_timeout`, and `allow_none`. |
5 | | -- Arguments to cached functions must be hashable; custom hash functions can be provided via the `hash_func` parameter for unhashable arguments. |
| 3 | +Welcome to the Cachier codebase! Please follow these guidelines to ensure code suggestions, reviews, and contributions are robust, maintainable, and compatible with our multi-backend architecture. |
| 4 | + |
| 5 | +## 1. Decorator and API Usage |
| 6 | + |
| 7 | +- The main decorator is `@cachier`. It supports parameters such as `stale_after`, `backend`, `mongetter`, `cache_dir`, `pickle_reload`, `separate_files`, `wait_for_calc_timeout`, `allow_none`, and `hash_func`. |
| 8 | +- Arguments to cached functions must be hashable; for unhashable arguments, provide a custom hash function via the `hash_func` parameter. |
6 | 9 | - The default backend is pickle-based, storing cache files in `~/.cachier/` unless otherwise specified. MongoDB and memory backends are also supported. |
7 | 10 | - Cachier is thread-safe and supports per-function cache clearing via the `clear_cache()` method on decorated functions. |
8 | | -- Global configuration is possible via `set_default_params` and `enable_caching`/`disable_caching` functions. |
9 | | -- When reviewing code, ensure new features or bugfixes maintain compatibility with Python 3.9+, preserve thread safety, and follow the numpy docstring conventions for documentation. |
10 | | -- Tests are located in the `tests/` directory and should be run with `pytest`. MongoDB-related tests require either a mocked or live MongoDB instance. |
11 | | -- When discussing or generating code, prefer concise, readable, and well-documented Python code, and follow the established conventions in the codebase and README. |
| 11 | +- Global configuration is possible via `set_default_params`, `set_global_params`, and `enable_caching`/`disable_caching`. |
| 12 | + |
| 13 | +## 2. Optional Dependencies and Backends |
| 14 | + |
| 15 | +- Cachier supports multiple backends: `pickle`, `memory`, `mongo`, and `sql`. |
| 16 | +- Not all dependencies are required for all backends. Code and tests for optional backends (e.g., MongoDB, SQL/SQLAlchemy) **must gracefully handle missing dependencies** and should not break import or test collection for other backends. |
| 17 | +- Only raise errors or warnings for missing dependencies when the relevant backend is actually used (not at import time). |
| 18 | + |
| 19 | +## 3. Testing Matrix and Markers |
| 20 | + |
| 21 | +- Tests are located in the `tests/` directory and should be run with `pytest`. |
| 22 | +- Tests are marked with `@pytest.mark.<backend>` (e.g., `@pytest.mark.sql`, `@pytest.mark.mongo`, `@pytest.mark.local`). |
| 23 | +- The CI matrix runs different backends on different OSes. Do **not** assume all tests run on all platforms. |
| 24 | +- MongoDB-related tests require either a mocked or live MongoDB instance. |
| 25 | +- When adding new backends that require external services (e.g., databases), update the CI matrix and use Dockerized services as in the current MongoDB and PostgreSQL setup. Exclude backends from OSes where they are not supported. |
| 26 | + |
| 27 | +## 4. Coverage, Linting, and Typing |
| 28 | + |
| 29 | +- Code must pass `mypy`, `ruff`, and `pytest`. |
| 30 | +- Use per-file or per-line ignores for known, justified issues (e.g., SQLAlchemy model base class typing, intentional use of `pickle`). |
| 31 | +- All new code must include full type annotations and docstrings matching the style of the existing codebase. |
| 32 | +- All docstrings should follow numpy docstring conventions. |
| 33 | + |
| 34 | +## 5. Error Handling and Warnings |
| 35 | + |
| 36 | +- Do **not** emit warnings at import time for missing optional dependencies. Only raise errors or warnings when the relevant backend is actually used. |
| 37 | + |
| 38 | +## 6. Backward Compatibility |
| 39 | + |
| 40 | +- Maintain backward compatibility for public APIs unless a breaking change is explicitly approved. |
| 41 | +- Cachier supports Python 3.9+. |
| 42 | + |
| 43 | +## 7. Documentation and Examples |
| 44 | + |
| 45 | +- When adding a new backend or feature, provide: |
| 46 | + - Example usage in the README |
| 47 | + - At least one test for each public method |
| 48 | + - Documentation of any new configuration options |
12 | 49 | - For documentation, follow numpy docstring conventions and validate changes to `README.rst` with `python setup.py checkdocs`. |
| 50 | + |
| 51 | +## 8. General Style |
| 52 | + |
| 53 | +- Prefer concise, readable, and well-documented Python code. |
| 54 | +- Follow the existing code style and conventions for imports, docstrings, and type annotations. |
| 55 | +- Prefer explicit, readable code over cleverness. |
| 56 | + |
| 57 | +______________________________________________________________________ |
| 58 | + |
| 59 | +Thank you for contributing to Cachier! These guidelines help ensure a robust, maintainable, and user-friendly package for everyone. |
0 commit comments