got a v1 version migrator that didn't change the version

[minrk]

I just got a version bump PR: conda-forge/fenics-basix-feedstock#28

but it doesn't change the version, it just added quotes around the version string and resets build number to zero:

 context:
   name: fenics-basix
-  version: 0.9.0
+  version: "0.9.0"
   # cxx_compiler_version not specified on Windows
   # extract from cxx_compiler
   cxx_compiler_version: ${{ cxx_compiler_version | default(cxx_compiler | replace("vs", "")) }}
@@ -18,7 +18,7 @@ source:
   sha256: 60e96b2393084729b261cb10370f0e44d12735ab3dbd1f15890dec23b9e85329
 
 build:
-  number: 3
+  number: 0
   variant:
     use_keys:

[beckermr]

The v1 version bump code is in rattler-build and has been not generating PRs for some feedstocks as well. I'd ask them what's up. Generally v1 version updates are broken right now.

I misspoke. Key bits are in rattler-build-conda-compat. See the code here:

https://github.com/regro/cf-scripts/blob/main/conda_forge_tick/update_recipe/version.py#L698

I'd add your recipe to the test suite and see what happens in that function.

[minrk]

Thanks for the pointer! I have a WIP raising a similar error to v0, which has a check for "did it actually change" not yet present in v1, which passes with the new recipe (in that it raises a similar error), which I guess would prevent the PR, but the real problem appears to be in whatever earlier code detects if a new version exists, but I haven't managed to find that yet. Do you have a link to that?

[beckermr]

Hmmmmm. What made you think the real problem was in the code that detects if a new version exists?

That code is here: https://github.com/regro/cf-scripts/blob/main/conda_forge_tick/update_upstream_versions.py

[beckermr]

@minrk I actually think the issue is in how v1 recipes are parsed into node attributes. If you look at this feedstocks metadata in the bot, the version is not currently "0.9.0":

https://github.com/regro/cf-graph-countyfair/blob/master/node_attrs/4/c/7/f/c/fenics-basix.json#L6683

I think this is because the v1 parser is pulling the package version from the output with the ABI version instead of using the top-level "recipe" metadata.

I don't fully follow what the change in name at the top-level is supposed to signify, but we should probably fix the v1 parser to pull that version before it tries to use an output.

[beckermr]

I think this block of code:

https://github.com/regro/cf-scripts/blob/main/conda_forge_tick/feedstock_parser.py#L516

needs to check the "recipe" top-level field if it exists.

[beckermr]

Actually this looks even worse. The top-level recipe.version is replaced by the output package.version and none of the other outputs have a version given after parsing.

[beckermr]

OK. This appears to have to do with the order of the outputs that rattler-build returns when rendering. There is no actual way for the bot to know which version to prefer. :/

[beckermr]

See this PR #4524

[minrk]

Got it, thanks. This is a lot more complicated than I realized. The v1 migrator effectively assumes that context.version contains the version, I think, so I didn't expect the outputs to be considered. I don't think the v1 migrator would work if context.version didn't contain the version to be bumped. Maybe that's related to whatever packages are not getting version bumps? All of my v1 recipes have been getting them just fine, I think (basix is the only weird one with this package-defined version).

[beckermr]

Agreed the context block might be required.