Developer Guide¶
This section provides guidelines for developers who want to contribute to the Optics Framework.
Note: Before contributing, please read our Contributing Guidelines to understand the contribution process.
1. Setting Up the Development Environment¶
To set up the development environment for the Optics Framework, follow these steps:
Clone the Repository¶
Clone the Optics Framework repository to your local machine using the following command:
Install Dependencies¶
Install the required dependencies using the following command:
For changes related to source code:
For changes related to documentation:
For default installation:
NOTE: We recommend using poetry to manage dependencies and virtual environments for the project. NOTE: For more info about pipx and poetry, refer to the pipx documentation and poetry documentation.
Install Pre-Commit Hooks¶
After installing dependencies, set up the pre-commit hooks to ensure code quality and commit message formatting:
This will install hooks that: - Run ruff for code linting and formatting - Run bandit for security checks - Validate commit messages using commitizen (Conventional Commits format) - Check for trailing whitespace, end-of-file issues, and YAML/JSON validity - Scan for secrets using gitleaks
NOTE: Pre-commit hooks will automatically run on git commit. You can also run them manually:
2. Create a New Branch¶
Before making any changes to the codebase, create a new branch for your contribution using the following command:
3. Make Changes¶
Work on your feature, bug fix, or documentation improvement in the appropriate directory:
- Source code:
optics_framework/ - Tests:
tests/ - Documentation:
docs/
Source Code Changes¶
- Make changes to the source code in the
optics_framework/directory.
Adhere to the project’s coding standards: Use Ruff for linting and formatting:
Or run both together:
NOTE: Ruff is configured to automatically fix issues where possible. The pre-commit hooks will also run Ruff automatically on commit.
Documentation Changes¶
- Make changes to the documentation in the
docs/directory. - Ensure the documentation is clear, concise, and follows the style guide.
- Use MkDocs for generating documentation.
For live changes while working on documentation: Use MkDocs to serve the documentation locally with auto-reload:
This will start a local server (typically at http://127.0.0.1:8000) that automatically reloads when you make changes to the documentation files.
To build the documentation for production:
Run Tests¶
Run the tests to ensure that your changes do not break existing functionality:
Packaging¶
To build the package:
4. Commit Changes¶
- Adhere to the Conventional Commits format for your commit messages.
- The pre-commit hooks will automatically validate your commit messages using
commitizen. - You can also use
commitizento help create properly formatted commit messages:
This will interactively guide you through creating a commit message that follows the Conventional Commits format.
NOTE: If you installed the pre-commit hooks (step 1.3), they will automatically run on each commit to check code quality and validate commit messages.