grayskull: [BUG] "Using .* with relational operator is superfluous and deprecated"
Consider the package dbt-core. The install_requires contains
"dbt-extractor~=0.4.1",
Running Grayskull this gets translated into
- dbt-extractor >=0.4.1,==0.4.*
Then running boa with conda mambabuild -c conda-forge . or conda build -c conda-forge . produces the warning
WARNING:conda.models.version:Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 0.4.*, but conda is ignoring the .* and treating it as 0.4
This results in the unsatisfiable dependency >=0.4.1,==0.4 since ==0.4 seems to imply 0.4.0 and excludes 0.4.1.
Interestingly, if I change it to a single equals (>=0.4.1,=0.4.*) then it doesn’t complain and seems to work as intended.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 27 (27 by maintainers)
Commits related to this issue
- Use "compatible release" operator ~= Building such recipes requires conda-build >=3.20.5 See https://github.com/conda-incubator/grayskull/issues/348 — committed to maresb/grayskull by maresb 2 years ago
- Use "compatible release" operator ~= (#365) Building such recipes requires conda-build >=3.20.5 See https://github.com/conda-incubator/grayskull/issues/348 — committed to conda/grayskull by maresb 2 years ago
- Fix "compatible release" operator See #348 — committed to maresb/grayskull by maresb 2 years ago
- Fix "compatible release" operator (#368) * Revert "Use "compatible release" operator ~= (#365)" This reverts commit ac333926af4236ce5a7617343e5b8d90364b716c. * Fix "compatible release" operator... — committed to conda/grayskull by maresb 2 years ago
I think, I just bumped into this (or at least it’s related).
One of my feedstocks has the requirements
~=0.9.0which gets translated to>=0.9.0,==0.9.*. This makes the solves throw an error despitev0.9.6being available.PR: https://github.com/conda-forge/aiofile-feedstock/pull/3 Logs: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=548936&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d
Oh yeah that’s maybe not a bad idea at all! @marcelotrevisani What do you think?
To be honest, I am not taking care much of pre-release versions because they shouldn’t be in conda-forge in general.
The dev can be added, it will need more tests.
Sometimes I’ll run
conda mambabuild recipelocally when testing a really problematic recipe. It seems like it would be really confusing if it failed locally but succeeded on CF.~=is not supported by conda-build: https://docs.conda.io/projects/conda-build/en/latest/resources/package-spec.html#build-version-specConda-forge just monkey patches it, iirc.