Update to v1 recipe format, and relax version constraint for pytest 9

[melund]

This PR updates the recipe format to v1, and relaxes the version constraint to allow the use of pytest 9.

pytest-split works fine with pytest 9 even thus the package doesn't explicitly say that it support it.

The problem with current constraint (^5 | ^6 | ^7 | ^8) is that it causes the solver to choose a much older version of the conda package (which didn't have the constraint), and that causes a problems since that version has a lot of differences to the new version.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[melund]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory. You can also examine the workflow logs for more detail.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20656882914. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the GitHub Actions workflow below for more details. You can also ping conda-forge/core (using the @ notation) for further assistance or you can try rerendering locally.

The following suggestions might help debug any issues:

• Is the recipe/{meta.yaml,recipe.yaml} file valid?
• If there is a recipe/conda-build-config.yaml file in the feedstock make sure that it is compatible with the current global pinnings.
• Is the fork used for this PR on an organization or user GitHub account? Automated rerendering via the webservices admin bot only works for user GitHub accounts.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20656797333. Examine the logs at this URL for more detail.}

[melund]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the GitHub Actions workflow below for more details. You can also ping conda-forge/core (using the @ notation) for further assistance or you can try rerendering locally.

The following suggestions might help debug any issues:

• Is the recipe/{meta.yaml,recipe.yaml} file valid?
• If there is a recipe/conda-build-config.yaml file in the feedstock make sure that it is compatible with the current global pinnings.
• Is the fork used for this PR on an organization or user GitHub account? Automated rerendering via the webservices admin bot only works for user GitHub accounts.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/20657013950. Examine the logs at this URL for more detail.}

[melund]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

[melund]

The pip check test still fails. Maybe it looks at the what pypi reports about the package dependencies. In that case we can't easily relax the dependencies here without disabling that test. I need to better understand the consequences of doing that before we proceed.

[maresb]

Hey, sorry for the delayed response here.

This is a common problem with conda, and my preferred approach is to take the package metadata as the main source of truth, but add upper bounds via https://github.com/conda-forge/conda-forge-repodata-patches-feedstock. I can show you how that goes, and this way pip check will pass.

Note that pip check failing is bad because this will cause it to fail on most environments containing that package, and that's why I prefer this approach.

[maresb]

See conda-forge/conda-forge-repodata-patches-feedstock#1131

[melund]

@maresb. It is kind of the opposite I wanted to do. I.e. relaxing the constraints instead of adding a upper bound.

The real problem is an older version of the package which did not have any constraints. So that is selected every time people try to upgrade the pytest dependency to version 9.

The package pytest-split does work fine with pytest 9, even though the source pyproject.toml restricts with this constraint ^5 | ^6 | ^7 | ^8.

If I could make a conda-package which relaxed this constraint, then it would not install the ancient version of the package which doesn't work.

[maresb]

Ya, I get it, but the way I see it, there are two distinct issues at play here:

1. The constraints are non-monotonic, so the solver must choose between either a newer version of pytest or a newer version of pytest-split.
2. pytest-split has a bound that forbids using the latest pytest.

I view 1. as in-scope for conda-forge, and having a pending solution in conda-forge/conda-forge-repodata-patches-feedstock#1131.

I view 2. as an upstream problem, reported in jerry-git/pytest-split#114. Having an upper-bound like this is generally a very bad idea, especially for maintainers who are not really on-top-of frequently testing and releasing.

What you're requesting here is that we override the author's compatibility determination. Sure it works for you with pytest 9, but how do we know there's not some deep reason that @jerry-git wanted to prevent pytest 9 use? What if pytest 10 breaks pytest-split? Moreover, if we override this here, then you will break most workflows that include pytest-split and run pip check.

If this is really an emergency situation, then we can discuss various strategies to mitigate this, but do you have such a pressing need for pytest 9 that you'd be willing to impose the aforementioned potential breakage? If not, then let's wait for @jerry-git to return from a presumed holiday vacation and fix the problematic bound.

[melund]

What if pytest 10 breaks pytest-split? Moreover, if we override this here, then you will break most workflows that include pytest-split and run pip check.

I agree. That will not do. I just didn't think that pip check used the PyPI meta info when running the checks. I thought the it was only looking at the packages in the environment. So my idea of patching the source did not work.

The constraints are non-monotonic, so the solver must choose between either a newer version of pytest or a newer version of pytest-split.

Yes. That would have been OK. But there is a very old version of pytest-split (with no constraints), which the solver then selects and hence breaks stuff.

I also agree that libraries should not constrain the package version unless there is a reason for it. In this case I suspect the constraint ^5 | ^6 | ^7 | ^8 was added to prevent pytest v4, but it should really have been implemented using (>=5).

[maresb]

Yes. That would have been OK. But there is a very old version of pytest-split (with no constraints), which the solver then selects and hence breaks stuff.

Can you be more specific about this? What's the very old version? Is it older than 0.8.2?

[melund]

Good question. I thought it was much older since pytest complained about invalid arguments:

ERROR: usage: pytest [options] [file_or_dir] [file_or_dir] [...]
pytest: error: argument --splitting-algorithm: invalid choice: 'least_duration' (choose from )

link to error

But the least_duration choice was present in 0.8.2, so there must be some other incompatibilities between 0.8.2 and pytest 9.

But the newest version (0.10.0) does work with pytest 9. I know because pixi can be forced to install it directly from pypi (my workaround).

It is also interesting that pip check fails when 0.8.2 is installed:

$ pixi add pytest>=9 pytest-split pip
✔ Added pytest>=9
✔ Added pytest-split >=0.8.2,<0.9
✔ Added pip >=25.3,<26
$ pixi run pip check
pytest-split 0.8.2 has requirement pytest<9,>=5, but you have pytest 9.0.2.

[maresb]

But the newest version (0.10.0) does work with pytest 9. I know because pixi can be forced to install it directly from pypi (my workaround).

Excellent! Very glad you found a workaround for now.

It is also interesting that pip check fails when 0.8.2 is installed:

Ooh, very good catch! I didn't start maintaining this until v0.10.0. I didn't check the version ranges, but I should have. It seems that there have been upper bounds for a while now. I need to investigate the situation in more detail and make a more thorough patch.

[maresb]

Ooh, very good catch!

See: conda-forge/conda-forge-repodata-patches-feedstock#1132

[melund]

Awesome, I hadn't seen the conda-forge-repodata-patches-feedstock before. Super cool.

[melund]

I will close this PR for now. I will monitor jerry-git/pytest-split#112 to see when upstream package gets updated.

[maresb]

Thanks @melund!

We could still upgrade this to v1 if you're interested.

[melund]

We could still upgrade this to v1 if you're interested.

Sure. Let me make a new PR.