|
1 | 1 | .. _contributing_as_a_developer: |
2 | 2 |
|
| 3 | +.. include:: ../../links.rst |
| 4 | + |
3 | 5 | Contributing as a developer |
4 | 6 | ########################### |
5 | 7 |
|
@@ -141,6 +143,175 @@ Finally, verify the installation by listing all the different environments |
141 | 143 | - {{ description }} |
142 | 144 | {% endfor %} |
143 | 145 |
|
| 146 | +.. _code-style: |
| 147 | + |
| 148 | +Code style |
| 149 | +========== |
| 150 | + |
| 151 | +PyDPF-Core follows the PyAnsys coding style guidelines to ensure consistent, |
| 152 | +readable, and maintainable code across the project. All contributors must |
| 153 | +adhere to these standards. |
| 154 | + |
| 155 | +Code formatting tools |
| 156 | +--------------------- |
| 157 | + |
| 158 | +PyDPF-Core uses `Ruff`_ as its primary code formatting and linting tool. |
| 159 | +Ruff is a fast Python linter and formatter that combines the functionality |
| 160 | +of multiple tools (like Black, isort, and Flake8) into a single package. |
| 161 | + |
| 162 | +The project configuration is defined in the ``pyproject.toml`` file with the |
| 163 | +following key settings: |
| 164 | + |
| 165 | +- **Line length**: 100 characters maximum |
| 166 | +- **Quote style**: Double quotes |
| 167 | +- **Import sorting**: Using isort rules with Ansys as a known first-party package |
| 168 | +- **Docstring convention**: NumPy style |
| 169 | + |
| 170 | +Pre-commit hooks |
| 171 | +---------------- |
| 172 | + |
| 173 | +PyDPF-Core uses `pre-commit`_ hooks to automatically check and format code |
| 174 | +before each commit. These hooks ensure that code styling rules are applied |
| 175 | +consistently across all contributions. |
| 176 | + |
| 177 | +To set up pre-commit hooks, install pre-commit and activate it: |
| 178 | + |
| 179 | +.. code-block:: bash |
| 180 | +
|
| 181 | + python -m pip install pre-commit |
| 182 | + pre-commit install |
| 183 | +
|
| 184 | +Once installed, the hooks will run automatically on ``git commit``. The following |
| 185 | +checks are performed: |
| 186 | + |
| 187 | +- **Ruff**: Linting and formatting |
| 188 | +- **Codespell**: Spell checking |
| 189 | +- **License headers**: Ensures all files have proper copyright headers |
| 190 | +- **Merge conflicts**: Detects merge conflict markers |
| 191 | +- **Debug statements**: Identifies leftover debug code |
| 192 | + |
| 193 | +You can also run pre-commit manually on all files: |
| 194 | + |
| 195 | +.. code-block:: bash |
| 196 | +
|
| 197 | + pre-commit run --all-files |
| 198 | +
|
| 199 | +Manual code formatting |
| 200 | +---------------------- |
| 201 | + |
| 202 | +If you prefer to format code manually without committing, you can run Ruff |
| 203 | +directly: |
| 204 | + |
| 205 | +.. code-block:: bash |
| 206 | +
|
| 207 | + # Format code |
| 208 | + python -m ruff format . |
| 209 | +
|
| 210 | + # Check and fix linting issues |
| 211 | + python -m ruff check --fix . |
| 212 | +
|
| 213 | + # Check without fixing |
| 214 | + python -m ruff check . |
| 215 | +
|
| 216 | +PEP 8 compliance |
| 217 | +---------------- |
| 218 | + |
| 219 | +PyDPF-Core follows `PEP 8 <https://peps.python.org/pep-0008/>`_ style guidelines, |
| 220 | +which are the official Python style guide. Ruff enforces most PEP 8 rules |
| 221 | +automatically. |
| 222 | + |
| 223 | +Key PEP 8 principles include: |
| 224 | + |
| 225 | +- Use 4 spaces for indentation (never tabs) |
| 226 | +- Limit line length to 100 characters (project-specific) |
| 227 | +- Use meaningful variable and function names |
| 228 | +- Follow naming conventions: |
| 229 | + |
| 230 | + - ``lowercase_with_underscores`` for functions and variables |
| 231 | + - ``CapitalizedWords`` for class names |
| 232 | + - ``UPPERCASE_WITH_UNDERSCORES`` for constants |
| 233 | + |
| 234 | +- Add appropriate whitespace around operators and after commas |
| 235 | +- Use docstrings for all public modules, functions, classes, and methods |
| 236 | + |
| 237 | +For complete details on PEP 8 and formatting best practices, refer to: |
| 238 | + |
| 239 | +- `PyAnsys Coding Style - PEP 8 Guidelines <https://dev.docs.pyansys.com/coding-style/pep8.html>`_ |
| 240 | +- `PyAnsys Coding Style - Formatting Tools <https://dev.docs.pyansys.com/coding-style/formatting-tools.html>`_ |
| 241 | + |
| 242 | +Docstring style |
| 243 | +--------------- |
| 244 | + |
| 245 | +PyDPF-Core uses the `NumPy docstring convention <https://numpydoc.readthedocs.io/en/latest/format.html>`_ |
| 246 | +for all documentation strings. This convention is enforced by Ruff's pydocstyle |
| 247 | +rules. |
| 248 | + |
| 249 | +Example of a properly formatted function docstring: |
| 250 | + |
| 251 | +.. code-block:: python |
| 252 | +
|
| 253 | + def calculate_stress(field, mesh, location="Nodal"): |
| 254 | + """Calculate stress values at specified locations. |
| 255 | +
|
| 256 | + Parameters |
| 257 | + ---------- |
| 258 | + field : Field |
| 259 | + Input field containing stress data. |
| 260 | + mesh : MeshedRegion |
| 261 | + Mesh region for the calculation. |
| 262 | + location : str, optional |
| 263 | + Location where stress is calculated. Default is ``"Nodal"``. |
| 264 | +
|
| 265 | + Returns |
| 266 | + ------- |
| 267 | + Field |
| 268 | + Calculated stress field. |
| 269 | +
|
| 270 | + Examples |
| 271 | + -------- |
| 272 | + >>> from ansys.dpf import core as dpf |
| 273 | + >>> stress_field = calculate_stress(field, mesh) |
| 274 | +
|
| 275 | + """ |
| 276 | + # Implementation here |
| 277 | + pass |
| 278 | +
|
| 279 | +Type hints |
| 280 | +---------- |
| 281 | + |
| 282 | +While not strictly enforced, using type hints is encouraged for better code |
| 283 | +clarity and IDE support. PyDPF-Core uses type hints extensively in its |
| 284 | +public API. |
| 285 | + |
| 286 | +Example with type hints: |
| 287 | + |
| 288 | +.. code-block:: python |
| 289 | +
|
| 290 | + from typing import Optional |
| 291 | + from ansys.dpf.core import Field, MeshedRegion |
| 292 | +
|
| 293 | + def process_field( |
| 294 | + field: Field, |
| 295 | + mesh: Optional[MeshedRegion] = None |
| 296 | + ) -> Field: |
| 297 | + """Process a field with optional mesh support.""" |
| 298 | + # Implementation here |
| 299 | + pass |
| 300 | +
|
| 301 | +Continuous integration checks |
| 302 | +------------------------------ |
| 303 | + |
| 304 | +All pull requests are automatically checked for code style compliance using |
| 305 | +GitHub Actions. Your code must pass these checks before it can be merged: |
| 306 | + |
| 307 | +- Ruff formatting and linting |
| 308 | +- Codespell checks |
| 309 | +- License header verification |
| 310 | +- Test suite execution |
| 311 | + |
| 312 | +If the CI checks fail, review the error messages and apply the necessary fixes |
| 313 | +before requesting a review. |
| 314 | + |
144 | 315 | .. _run-tests: |
145 | 316 |
|
146 | 317 | Run the tests |
@@ -240,18 +411,18 @@ For example, to run compatible parallel tests while using a Standalone DPF Serve |
240 | 411 | `takes precedence <https://dpf.docs.pyansys.com/version/dev/getting_started/dpf_server.html#manage-multiple-dpf-server-installations>`_ |
241 | 412 | over any other DPF Server installation method. Therefore, a standalone DPF Server installed in editable mode, in the |
242 | 413 | presence of ANSYS_DPF_PATH environment variable, will be ignored. |
243 | | - |
| 414 | + |
244 | 415 | With tox, a simple workaround is not setting this environment variable at the operating system level but passing it explicitly only when |
245 | 416 | required. This is achived by adding ``-x testenv.setenv+="ANSYS_DPF_PATH=<path/to/valid/DPF/Server/installation>"`` to any tox command. |
246 | | - |
| 417 | + |
247 | 418 | Alternatively, when set at the operating system level, commenting out the line where this environment variable is passed in the tox |
248 | 419 | configuration file will ensure that it is ignored within the tox environments. |
249 | 420 |
|
250 | 421 | .. image:: tox.png |
251 | 422 |
|
252 | 423 | Testing on Linux via WSL |
253 | 424 | ------------------------ |
254 | | -Some system dependencies required for VTK to run properly might be missing when running tests on linux via WSL (or even linux in general). |
| 425 | +Some system dependencies required for VTK to run properly might be missing when running tests on linux via WSL (or even linux in general). |
255 | 426 | The identified workaround for this is to install the OSMesa wheel variant that leverages offscreen rendering with OSMesa. |
256 | 427 | This wheel is being built for both Linux and Windows at this time and bundles all of the necessary libraries into the wheel. This is |
257 | 428 | achieved by adding ``-x testenv.commands_pre="uv pip install --index-url https://wheels.vtk.org vtk-osmesa==<version>"`` |
|
0 commit comments