Skip to content

Commit 2800d4e

Browse files
Copilotrozyczko
andauthored
✨ Set up Copilot instructions for EasyReflectometryLib (#277)
* Initial plan * Add GitHub Copilot instructions for EasyReflectometryLib Co-authored-by: rozyczko <[email protected]> * Address code review feedback for Copilot instructions Co-authored-by: rozyczko <[email protected]> * Fix formatting of myst_parser package name Co-authored-by: rozyczko <[email protected]> --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: rozyczko <[email protected]>
1 parent 91dd99b commit 2800d4e

File tree

1 file changed

+181
-0
lines changed

1 file changed

+181
-0
lines changed

.github/copilot-instructions.md

Lines changed: 181 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,181 @@
1+
# GitHub Copilot Instructions for EasyReflectometryLib
2+
3+
## Project Overview
4+
5+
EasyReflectometryLib is a reflectometry Python package built on the EasyScience framework. It provides tools for reflectometry analysis and modeling.
6+
7+
## Development Environment
8+
9+
- **Python Versions**: 3.11, 3.12
10+
- **Supported Platforms**: Linux (ubuntu-latest), macOS (macos-latest), Windows (windows-latest)
11+
- **Package Manager**: pip
12+
- **Build System**: hatchling with setuptools-git-versioning
13+
14+
## Code Style and Formatting
15+
16+
### Ruff Configuration
17+
- Use **Ruff** for linting and formatting (configured in `pyproject.toml`)
18+
- Maximum line length: 127 characters
19+
- Quote style: single quotes for strings
20+
- Import style: force single-line imports
21+
- To fix issues automatically: `python -m ruff . --fix`
22+
23+
### Code Quality Standards
24+
- Follow PEP 8 guidelines
25+
- Use type hints where appropriate
26+
- Write clear, self-documenting code with meaningful variable names
27+
- Maintain consistency with existing code patterns in the repository
28+
29+
### Linting Rules
30+
The project uses Ruff with the following rule sets:
31+
- `E9`, `F63`, `F7`, `F82`: Critical flake8 rules
32+
- `E`: pycodestyle errors
33+
- `F`: Pyflakes
34+
- `I`: isort (import sorting)
35+
- `S`: flake8-bandit (security checks)
36+
37+
Special notes:
38+
- Asserts are allowed in test files (`*test_*.py`)
39+
- Init module imports are ignored
40+
- Exclude `docs` directory from linting
41+
42+
## Testing
43+
44+
### Test Framework
45+
- Use **pytest** for all tests
46+
- Test coverage should be tracked with **pytest-cov**
47+
- Aim for comprehensive test coverage
48+
- Tests are located in the `tests/` directory
49+
50+
### Running Tests
51+
```bash
52+
# Install dev dependencies
53+
pip install -e '.[dev]'
54+
55+
# Run tests with coverage
56+
pytest --cov --cov-report=xml
57+
58+
# Run tests using tox (for multiple Python versions)
59+
pip install tox tox-gh-actions
60+
tox
61+
```
62+
63+
### Test Guidelines
64+
- Write unit tests for all new functionality
65+
- Include tests when fixing bugs to prevent regression
66+
- Test files should match the pattern `test_*.py`
67+
- Use descriptive test function names that explain what is being tested
68+
- Follow the existing test structure and patterns in the repository
69+
70+
## Security
71+
72+
- Follow flake8-bandit security guidelines (enabled via Ruff `S` rules)
73+
- Be cautious with user input and file operations
74+
- Do not commit secrets or sensitive information
75+
- Review security implications of all changes
76+
77+
## Documentation
78+
79+
### Docstring Style
80+
- Include docstrings for all public modules, classes, and functions
81+
- Use **Sphinx/reStructuredText style** docstrings (`:param`, `:type`, `:return`, `:rtype`)
82+
- Use clear, concise descriptions
83+
- Document parameters, return values, and exceptions
84+
- Example format:
85+
```python
86+
"""
87+
Brief description of the function.
88+
89+
:param param_name: description of parameter
90+
:type param_name: type
91+
:return: description of return value
92+
:rtype: return_type
93+
"""
94+
```
95+
96+
### Documentation Build
97+
- Documentation is built using Sphinx (version 8.1.3)
98+
- Source files are in the `docs/` directory
99+
- Use `myst_parser` (MyST parser) for Markdown support
100+
- Include code examples in documentation where appropriate
101+
102+
## Dependencies
103+
104+
### Core Dependencies
105+
- easyscience (EasyScience framework)
106+
- scipp (Scientific computing)
107+
- refnx, refl1d (Reflectometry calculations)
108+
- orsopy (Data format support)
109+
- bumps (Optimization)
110+
111+
### Adding New Dependencies
112+
- Only add dependencies when absolutely necessary
113+
- Add to appropriate section in `pyproject.toml`:
114+
- `dependencies` for core runtime dependencies
115+
- `dev` for development tools
116+
- `docs` for documentation building
117+
- Document why the dependency is needed
118+
119+
## Git and Version Control
120+
121+
### Commit Messages
122+
- Write clear, descriptive commit messages
123+
- Use present tense ("Add feature" not "Added feature")
124+
- Reference issue numbers when applicable
125+
126+
### Branch Workflow
127+
- Create feature branches from the main branch
128+
- Use descriptive branch names (e.g., `feature/add-new-calculator`, `bugfix/fix-reflection-calculation`)
129+
- Keep changes focused and atomic
130+
131+
## Pull Request Guidelines
132+
133+
1. Include tests for new functionality
134+
2. Update documentation if adding or changing features
135+
3. Ensure all CI checks pass:
136+
- Code consistency (Ruff)
137+
- Code testing (pytest on all supported platforms/versions)
138+
- Package building
139+
4. Code should work on Python 3.11, 3.12 and all supported platforms
140+
5. Write a clear PR description explaining the changes
141+
142+
## Project Structure
143+
144+
```
145+
src/easyreflectometry/ # Main package source code
146+
├── calculators/ # Calculator implementations (refnx, refl1d)
147+
│ └── bornagain/ # BornAgain calculator (not yet functional)
148+
├── model/ # Reflectometry models
149+
├── sample/ # Sample structures and materials
150+
├── special/ # Special calculations and parsing
151+
├── summary/ # Summary generation
152+
└── project.py # Main project interface
153+
154+
tests/ # Test suite
155+
docs/ # Documentation source
156+
```
157+
158+
## Best Practices
159+
160+
1. **Minimal Changes**: Make the smallest possible changes to accomplish the task
161+
2. **Don't Break Existing Code**: Maintain backward compatibility unless explicitly required
162+
3. **Test Before Committing**: Always run tests and linting before pushing
163+
4. **Follow Existing Patterns**: Look at similar code in the repository for guidance
164+
5. **Ask When Uncertain**: If unsure about an approach, ask for clarification
165+
166+
## CI/CD Pipeline
167+
168+
The project uses GitHub Actions for continuous integration:
169+
- **Code Consistency**: Runs Ruff linting on all pushes and PRs
170+
- **Code Testing**: Runs pytest across multiple Python versions and platforms
171+
- **Package Testing**: Validates package building and installation
172+
- **Coverage**: Uploads test coverage to Codecov
173+
174+
All CI checks must pass before merging PRs.
175+
176+
## Special Notes
177+
178+
- The project is part of the EasyScience ecosystem
179+
- Built on top of established reflectometry libraries (refnx, refl1d)
180+
- Focuses on providing a user-friendly interface for reflectometry analysis
181+
- Maintains compatibility with multiple calculator backends

0 commit comments

Comments
 (0)