@@ -183,3 +183,69 @@ Workflow examples are provided for various checks, such as :ref:`code style <cod
183
183
184
184
.. literalinclude :: code/release.yml
185
185
:language: yaml
186
+
187
+ Importance of pinned dependencies
188
+ ---------------------------------
189
+
190
+ .. note ::
191
+
192
+ This guidance applies to CI workflows. It does apply to the
193
+ `dependency version range <https://dev.docs.pyansys.com/how-to/packaging.html#dependency-version-range >`_.
194
+ of the project itself.
195
+
196
+ To guarantee reproducibility, stability, and predictability of workflows, it is critical that
197
+ CI uses a locked, fully resolved list of pinned versions. If a project allows floating
198
+ versions of dependencies, for example `numpy>=1.26 `, to be used in CI, it is exposed to random
199
+ failures without any code change. In fact, problems can occur at different levels:
200
+
201
+ - Runtime bugs: Update in runtime dependencies, like `numpy ` or `pandas `, can introduce changes
202
+ in API behavior, deprecations, or regressions, affecting production code.
203
+ - Test failures: A minor update of a testing library could introduce breaking changes or
204
+ modify test behavior, causing false negatives or false positives.
205
+ - Documentation build breaks: A documentation generator like `Sphinx ` might introduce
206
+ subtle or breaking changes, like new warnings treated as errors or theme updates breaking
207
+ rendering, causing your docs build to fail.
208
+
209
+ Pinning dependencies avoid these issues by freezing exact versions and ensure that CI
210
+ workflows are reliable and predictable.
211
+
212
+ Additionally, having a complete, pinned set of dependencies is very useful for users and
213
+ contributors. If an user encounters issues while running tests locally, using the frozen
214
+ dependencies from CI could fix the problems or provide a reproducible environment for debugging.
215
+ Overall, this improves support, debugging speed, and community contribution experience.
216
+
217
+ How to pin dependencies
218
+ -----------------------
219
+
220
+ Depending on the type of project, different tools can be used to manage and pin dependencies.
221
+ In the following, we assume that your project has defined
222
+ `optional installation targets <https://dev.docs.pyansys.com/how-to/packaging.html#optional-target-recommendations-in-the-pyansys-ecosystem >`_
223
+ to illustrate how to install specific subsets of dependencies.
224
+
225
+ If you are using `poetry <https://python-poetry.org/ >`_, you can use the ``poetry lock ``
226
+ command to generate a ``poetry.lock `` file with all the dependencies and their versions.
227
+ Once the lock file created, you can use the following command in your CI workflow to install
228
+ the project with `tests ` dependencies:
229
+
230
+ .. code-block :: yaml
231
+
232
+ - name : Install dependencies with extra tests
233
+ run : |
234
+ poetry install --with tests
235
+
236
+ If your project uses `flit ` or `hatch `, you can use `uv <https://github.com/astral-sh/uv >`_
237
+ to fastly resolve the dependencies and generate a requirements file. You can use the
238
+ ``uv pip compile -o requirements.txt pyproject.toml `` command to generate a ``requirements.txt ``
239
+ file with the main dependencies defined in your project. Note that, contrary to the
240
+ ``poetry.lock `` file, the requirements file does not include the variations for each installation
241
+ target. To create a requirements file with a specific extra, you can use the ``--extras `` option.
242
+ For example, you can create a requirement file with the `tests ` extra by running the
243
+ ``uv pip compile --extra tests -o requirements-tests.txt pyproject.toml ``. Once the file created,
244
+ you can use the following command in your CI workflow to install the project with `tests `
245
+ dependencies:
246
+
247
+ .. code-block :: yaml
248
+
249
+ - name : Install dependencies with extra tests
250
+ run : |
251
+ pip install -r requirements-tests.txt
0 commit comments