feat: update version and build number for v2 recipes

[wolfv]

We haven't actually released a new version of the rattler-build-conda-compat package. This can be considered a draft-PR for what it should look like.

[beckermr]

I do not want to move the code in this direction.

rattler-build is an implementation of the v2 spec and possibly not the only one. Bot items like updating build numbers, version bumps, etc. should be independent of the backend spec implementation as much as possible.

If you all would like contribute to items like this to conda-recipe-manager, that'd be a way to not have them directly in this code base.

[wolfv]

I have no problems to put the code directly in the cf-scripts repo (it's just some duplication).

I am not sure where you see the difference between the "rattler-build-conda-compat" and "conda-recipe-manager" packages? Is it just the name? :)

[wolfv]

Just to be clear - the code in rattler-build-conda-compat is pure Python.

[wolfv]

I looked at it some more and I do think that it would be quite a lot of duplication (ie. the whole Jinja rendering logic and conditional list traversal logic would need to be duplicated).

On the other hand, no problem for me to copy it over if that's the preference! :)

[beckermr]

My main concerns are three-fold.

First, we have a proliferation of recipe editing tools / approaches. We have at least three existing approaches right now:

1. https://github.com/marcelotrevisani/souschef
2. this repo's own parser for v1: https://github.com/regro/cf-scripts/tree/master/conda_forge_tick/recipe_parser
3. https://github.com/conda-incubator/conda-recipe-manager

The first two date back to ~4 years ago and I am not sure about conda-recipe-manager. IMHO we should not be adding another.

Second, I agree with Isuru's concern about rattler branding in general.

Third, I don't like splitting code out of this repo in ways that potentially create cross-package debugging and/or cross-package release issues. Should code in the other package(s) fail, then the release process for fixes becomes more complicated.

If we

• centralize the editing functionality into a single package that can handle v1 and v2 recipes
• deprecate + remove the parser here once conda-recipe-manager can handle everything the parser here can
• add v2 editing capability to conda-recipe-manager as needed

then we'd be in a better spot all around.

[wolfv]

Closing in favor of #2920