pytest-step in provided GitHub action prefers remote package over local

[lukaslueg]

Bug Description

The Github-action generated by Maturin may contain default steps for running pytest. The juicy parts of those pytest-step are:

set -e
pip install [package] --find-links dist --force-reinstall
pip install pytest
pytest

I noticed that CI started to fail after releasing a new version, and then adding new commits. The problem is that the pip install [package] prefers the remote package over the locally built wheel in dist if the version-number is the same. Therefor, the tests execute against an outdated package as long as the version number is not bumped. This seems highly surprising behavior.

Your maturin version (maturin --version)

1.4.0

Your Python version (python -V)

3.11

Your pip version (pip -V)

23.3

What bindings you're using

pyo3

Does cargo build work?

• Yes, it works

If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash /)?

• Yes

Steps to Reproduce

1. Bump version, release to pypi
2. Add commits
3. The CI-pipeline provided by Maturin starts testing the pypi-provided package, instead of HEAD.
4. Bump the package-version and push; pytest now (and only now) starts using the package built by sdist from HEAD.

[messense]

See also #1680

[baseplate-admin]

I am really tired after 72 hours of debugging.

I have commented on pip:

• pip install --find-links dist no longer prefers local over PyPI (fails maturin CI) pypa/pip#12110 (comment)

[baseplate-admin]

Hi @messense,

Would you be willing to switch to uv from pip?

Suggested by : pypa/pip#12110 (comment)

[messense]

You can already do that by modifying the generated the CI configuration file.

Adding uv support to generate-ci is welcome, we already have uv support in maturin develop command.

[baseplate-admin]

UV now supports local directories lookup with this pr:

• Add support for local directories with --index-url astral-sh/uv#4226

[chrysn]

As a workaround, I've added --no-index to my project before every --find-links – that works at least for the Linux and Windows targets (there is a dist in there and it contains some wheels, but apparently not to pip's liking).

I'd guess that this workaround as it is is limited to packages without dependencies; packages with dependencies would need to install the dependencies prior to the --no-index --find-links dist installations, or do an install without --no-index first, uninstall, and reinstall with --no-index --find-links (which works only as long as the package has not acquired new dependencies since the last release).