Add multiformats

[lkluft]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[github-actions]

Hi! This is the staged-recipes linter and I found some lint.

File-specific lints and/or hints:

• recipes/multiformats-config/meta.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: d70-t. Please ask them to comment on this PR if they are.

• recipes/bases/meta.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: d70-t. Please ask them to comment on this PR if they are.

• recipes/typing-validation/meta.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: d70-t. Please ask them to comment on this PR if they are.

• recipes/multiformats/meta.yaml:

  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: d70-t. Please ask them to comment on this PR if they are.

[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 (recipes/multiformats/meta.yaml, recipes/multiformats-config/meta.yaml, recipes/bases/meta.yaml, recipes/typing-validation/meta.yaml) and found it was in an excellent condition.

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

For recipes/multiformats/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/multiformats-config/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/bases/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

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

[d70-t]

I can help out maintaining from time to time.

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/multiformats/meta.yaml, recipes/typing-validation/meta.yaml, recipes/bases/meta.yaml, recipes/multiformats-config/meta.yaml) and found some lint.

Here's what I've got...

For recipes/multiformats/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/typing-validation/meta.yaml:

• ❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

For recipes/typing-validation/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/bases/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/multiformats-config/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

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

[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 (recipes/multiformats/meta.yaml, recipes/bases/meta.yaml, recipes/typing-validation/meta.yaml, recipes/multiformats-config/meta.yaml) and found it was in an excellent condition.

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

For recipes/multiformats/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/bases/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/typing-validation/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/multiformats-config/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

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

[lkluft]

Thanks for your comments!

I am not really sure about the python_min variable though. Removing the variable altogether leads to crashes in Jinja2 because the variable is unset. Is it fine to just don't require a minimum python in those cases?

[xhochy]

The variable should be set to a default of 3.9 (the minimal supported version).

[lkluft]

Okay, thanks 👍 I set python_min = "3.9" in all recipes and cleaned the mess of back-and-forth fixes.

[xhochy]

Okay, thanks 👍 I set python_min = "3.9" in all recipes and cleaned the mess of back-and-forth fixes.

No, you should not set it all.

[lkluft]

Unsetting python_min causes the Jinja2 exception (see latest pipeline). I am a bit puzzled by this as I have seen other recipes with the same configuration pass.

One hack would be to set {% set python_min = python_min | default("3.9") %}, e.g. using the build system value if present, but not failing otherwise. But there may be another problem with the recipes.

[d70-t]

@conda-forge-admin please rerender

(I'm trying to follow this advice.)

[d70-t]

I tried debugging this a little more. I just found by building locally, that the packen typing-validation (which can be built without further dependencies) would build fine, if it is the only package in this change, but it crashes with the python_min error, if there are other packages / receipes to be built in the same change. So I guess options for moving forward would be:

• split this PR into four, one for each receipe
• try finding out what's the issue when building multiple receipes at once

[d70-t]

Apparently, this issue has already been seen at #28445

[d70-t]

There's apparently a hack at #28494, which seems to fix the problem when adding multiple recipes in one PR. Should we try that?

[lkluft]

I will close this issue and reopen the PRs for the individual recipes