Update version/build constraints for rattler-build compat

[mgorny]

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.

Update the version strings not to use redundant =, and to match build strings as a separate field rather than appended to the version via =. This is necessary for feedstocks built using rattler-build to be able to depend on libabseil.

Fixes #84

[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/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

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

[h-vetinari]

I'm sorry, I don't want to block your work, but I disagree fundamentally with this. Rattler needs to be able to handle = signs, not only because they're valid specs, but more importantly, because we really should not encourage syntax that depends on significant whitespace (e.g. libabseil *cxx{{ cxx_standard }}* vs. libabseil * cxx{{ cxx_standard }}*).

The build string syntax is horrible (c.f. conda/conda#11053), and I do not want to make it even more horrible by relying on significant whitespace.

CC @wolfv @baszalmstra

[mgorny]

Filed as prefix-dev/rattler-build#1265.

[wolfv]

Bas has a longer explanatory comment here: https://conda-forge.zulipchat.com/#narrow/channel/457337-general/topic/rattler-build.20.22strict.22.20matchspec.20parsing/near/488975665

[h-vetinari]

From @baszalmstra's comment:

foo=1.0=py27_0 handling of ambigous equals signs is removed in strict mode. The reasoning is that foo=1.0 means foo 1.0.* while foo=1.0=* means foo ==1.0 *.

I fail to see any ambiguity here. Having an equal sign after the version means whatever comes after is qualifying the build string. The ambiguity is much worse IMO between

foo 1.0.*  # means foo ==1.0.*
foo 1.0 *  # means foo ==1.0[build=*]
       ^

IOW, the equals-variant is much less ambiguous visually.

[wolfv]

A fix is coming: prefix-dev/rattler-build#1271 - will be released this week.

[wolfv]

We fixed the issue in 0.33.0 with the constraints coming from upstream, ie. this fix here is not needed anymore.

The parsing of the input is now much stricter though and doesn't allow for foo 1.2 anymore, but are required to use 1.2.* or ==1.2 depending on what you want.

=1.2=abc is also not allowed in strict mode as it is also confusing.

If you want something visually appealing, you can use foo [version="1.2.*", build="*cuda"].

[h-vetinari]

The parsing of the input is now much stricter though and doesn't allow for foo 1.2 anymore, but are required to use 1.2.* or ==1.2 depending on what you want.

This feels like a big hammer for very little gain, i.e. it'll break lots of recipes, and there's basically no packages with variable version depth (e.g. 1.2 and 1.2.1) where the distinction would make sense, much less that someone would then want to exactly pin to 1.2 rather than 1.2.*.

Yes, it's more correct and more expressive. But in terms of our breakage budget, the benefit doesn't seem justified. Hopefully you have good error messages.

=1.2=abc is also not allowed in strict mode as it is also confusing

Can you explain to me like I'm 5 what aspect is confusing with this syntax?

[wolfv]

It uses an equal sign which usually means complete equality.

[wolfv]

Regarding breakage - very few packages have this syntax (foo 1.2). Most already use a range. The error message is very clear.

[h-vetinari]

It uses an equal sign which usually means complete equality.

Which it does, unless you use wildcards, which are a very explicit choice about which parts do not need to match. Are you saying that =cuda* is not "complete equality", and thus = is inappropriate?

[wolfv]

Your example was =1.2=cuda* which is, for a layperson, hard to understand. First of all, it looks like a pretty confusing jumble of characters - is = part of the version?

The first part is =1.2 which has the ambiguity about wether this matches 1.2.0 exclusively, or wether it matches 1.2.*. For example, on pip/pypi these are not allowed either, you have to use ==1.2 or >=1.2 or 1.2.*, etc.

And then why is it =? Couldn't it be 1.2\cuda* or another character? Equals also means "equal" after all, so IMO it's not a good separator character for a constraint.

So yes, we now require a real operator that is not confusing. If you can come up with a different, better looking separator character than whitespace or equal, we can discuss it! :)

[wolfv]

Could be 1.2@build*

Or 1.2#build*

[h-vetinari]

Your example was =1.2=cuda* which is, for a layperson, hard to understand. First of all, it looks like a pretty confusing jumble of characters - is = part of the version?

I never said I liked it, but it's still better than pytorch * cuda* where it's completely magical what happens. With =, at least it's clear that there's a separation between components.

And then why is it =? Couldn't it be 1.2\cuda* or another character? Equals also means "equal" after all, so IMO it's not a good separator character for a constraint.

But it is used for equality (of the build string). Yes, I would like to get away from these kind of build-string shenanigans completely¹, but = is an obvious choice for the separator there, both semantically, and to keep things consistent (i.e. users having to ask themselves "what was the separator for the build string again?")

On top of that, even if you personally dislike it, it's widely deployed, which in itself puts a massive burden of proof on any changes to this. If - as you seem to suggest - we're going to start requiring new syntax to be supported by all installers, then let's write a CEP (for something between conda/conda#11053 and your [...] syntax), but let's not just unilaterally break long-standing syntax based on a purely stylistic preference.

Footnotes

1. xref https://github.com/conda/conda/issues/11053 again, which is broadly in the same direction as your foo [version="1.2.*", build="*cuda" ↩

[wolfv]

It's only not allowed in recipes as input specs (e..g in build/host/run). A normal conda-build spec with whitespaces is what is emitted at the end into the repodata.json / index.json.

[wolfv]

The [ ... ] syntax is btw. regular conda matchspec syntax :)

[h-vetinari]

It's only not allowed in recipes as input specs (e..g in build/host/run).

I get that, but so far you haven't managed to make a convincing argument why this should be the case. You say "it's not really equality", but it uses the same mechanism as version comparison with wildcards does:

=1.2.*       # fuzzy version matching
...=abc*     # fuzzy buildstring matching
=1.2.*=abc*  # both

A normal conda-build spec with whitespaces is what is emitted at the end into the repodata.json / index.json.

The fact that it's used for the backend syntax doesn't mean we have to pessimize the user-facing one. IMO pytorch * cuda* is unequivocally worse than pytorch =*=cuda*.

The [ ... ] syntax is btw. regular conda matchspec syntax :)

Yes, and it has all the same buildstring-matching & -overload problems, just within [...].

[wolfv]

But =1.2 means 1.2.* :)

[h-vetinari]

But =1.2 means 1.2.* :)

I'm on board with cleaning up the version-range issues (which are almost fully orthogonal here). My point is:

foo <verspec> <stringspec>

should be equivalent to

foo =<verspec>=<stringspec>

If you remove the version-range confusion, then the build strings are not confusing at all.

[mgorny]

If that means anything, bash also uses = (and ==, !=) operators for string pattern matching, so I don't find = with a pattern on RHS is surprising.

[mgorny]

Closing since rattler-build has been fixed.