add run_constrained on xz from liblzma

[minrk]

suggested alternative in conda-forge/conda-forge-repodata-patches-feedstock#936

still needs a repodata patch to apply this constraint to the published liblzma so far to fully address the conflict for older xz

[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). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.

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

[h-vetinari]

You don't need the build number, because the split was introduced with a new version (#42). So already the version constraint avoids pulling in old builds. I would just say

Suggested change

	- xz =={{ version }} *_{{ build }}
	# avoid co-installation with pre-split xz packages
	- xz =={{ version }}

[minrk]

The build number is required for consistency with the future, e.g. to avoid introducing the same problem again in a later refactor. The split could have happened within a version, and similar changes could happen in the future within a version, so I think this is the safest and most correct way to go (pin_subpackage("xz", exact=True) is certainly what should go here, but doesn't work for circular dependency reasons).

FWIW, I tried =={{ version }}[build={{ build }}] which I believe is valid and avoids the build string glob, but conda-build mistakenly parses that matchspec as a selector comment, leading to an error.

[h-vetinari]

The split could have happened within a version, and similar changes could happen in the future within a version [...]

It very plainly didn't happen within a version, and we shouldn't try to prematurely optimize for a completely hypothetical split, which (if it ever happens), will be responsible for handling its own migration story.

Ultimately I'm not a maintainer on this feedstock though, so I'll leave this to y'all to hash out.

[minrk]

I'm just not sure what the downside is, when the intended constraint seems pretty clearly to be "this build of this package" which is version + build number. If there's a downside I'm happy to go with something better, I just don't see what it would be.