feat: use uv lock file

[SMoraisAnsys]

Follow up of #1364 but with a clean branch.

Related to #1088, in particular this comment, and #1088.

Testing in pyaedt was successfull and highlighted that fonttools, a transitive dependency, was associated to a vulnerability in Safety's db. This is not a universal id like CVE/GHSA.

The use of uv add --group ansys-actions -r "${REQUIREMENTS_FILE}" has been removed in 10ddec7 because some hooks might check the pyproject.toml / uv.lock files and lead to CI failure. That is the case with pyansys-geometry which leverages pyproject-fmt.

The smoke_test.py file has been updated in 6932c1a to be compatible with uv's architecture to manage packages. I assume that we we weren't affected previously because uv pip install mimics pip's behavior. But when using uv sync that behavior changes and we can't use CWD to retrieve the dist files. Levering relative location solves this issue and seems to also work with other package managers.

Note

Currently the changes are limited to a subset of actions. We might want to extend it to others. TBD

[SMoraisAnsys]

Adding a comment to remind the need to revert some CI changes before any merge

[moe-ad]

Thanks for the changes @SMoraisAnsys, I left a couple of comments.

There is one other thing I have been thinking about, why can't we just use the uv lock files automatically once detected rather than exposing an explicit input for it (similar to how there is no input for poetry). IMO, a project that already uses a lock file would expect its dependencies to be install from it.

[moe-ad]

I suggest creating a separate workflow (ci_cd_pr_uv ?) for testing projects that have started moving to uv to keep things clean and separated, and to have a natural place for testing more uv projects in the future (quite a number of them now). What do you think?

Although pyansys-geometry is using a hatchling build backend instead of uv_build, we could still test all projects leveraging uv lock files but not using any of flit_core.buildapi/poetry.core.masonry.api build backends in ci_cd_pr_uv.

[SMoraisAnsys]

That was just a CI config to illustrate that the changes work. Having another test workflow is a good idea but shouldn't we wait for uv_build to be used ?

[moe-ad]

INSTALL_TARGET can be used directly rather than creating a separate env variable.

[SMoraisAnsys]

Unfortunately this is not possible because INSTALL_TARGET would be . or .[my-target] (I just tested the changes :') ) Also, this env var is used when creating the wheel so better keep things as they are.

[moe-ad]

Out of curiosity, why this change? Did the previous implementation start failing?

[SMoraisAnsys]

This is described in the PR description. Let me know if that's not clear enoguh

[moe-ad]

Suggested change

use-uv: ${{ matrix.repository.name == 'pyansys-geometry' }}

use-uv is true by default in the actions, which means we were always testing this execution path for every project. This change now means it will be only be tested for pyansys-geometry, which is not what you intended I suppose.

[SMoraisAnsys]

This is a temporary ci config and planned to be reverted (cf #1427 (comment))

[SMoraisAnsys]

Thanks for the changes @SMoraisAnsys, I left a couple of comments.

There is one other thing I have been thinking about, why can't we just use the uv lock files automatically once detected rather than exposing an explicit input for it (similar to how there is no input for poetry). IMO, a project that already uses a lock file would expect its dependencies to be install from it.

I'm fine with detecting it and activating it by default. My only concern is the sudden change of behavior for people that still work with version tag and/or don't read every release note carefully.