FEAT: Add tardigrade_error_tools

[NateAM]

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.

[NateAM]

@kbrindley will you comment on this PR to say you are willing to be a maintainer?

[github-actions]

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

File-specific lints and/or hints:

• recipes/tardigrade_error_tools/meta.yaml:
  • lints:
    • The following maintainers have not yet confirmed that they are willing to be listed here: kbrindley. 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 wanted to let you know that I linted all conda-recipes in your PR (recipes/tardigrade_error_tools/meta.yaml) and found some lint.

Here's what I've got...

For recipes/tardigrade_error_tools/meta.yaml:

• ❌ Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [29]

For recipes/tardigrade_error_tools/meta.yaml:

• ℹ️ The boost output has been superseded by libboost-python-devel (as of 1.82), which now comes with a run-export (on libboost-python) as well.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/15433070263. 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/tardigrade_error_tools/meta.yaml) and found it was in an excellent condition.

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

For recipes/tardigrade_error_tools/meta.yaml:

• ℹ️ The boost output has been superseded by libboost-python-devel (as of 1.82), which now comes with a run-export (on libboost-python) as well.

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

[kbrindley]

I am willing to be a maintainer

[github-actions]

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

[NateAM]

@conda-forge/help-c-cpp This is ready for review

[NateAM]

@conda-forge-admin, please ping conda-forge/help-c-cpp

Just in case I hadn't signaled this was ready for review properly

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/help-c-cpp and so here I am doing that.

[danielnachun]

Suggested change

	skip: true # [osx or win]
	skip: true # [osx or win]

This software does not seem to be Linux-only, so we should at least enable OSX and see if there are any fixable errors. Windows may be trickier, although since this is using CMake and doesn't appear to have any dependency that are not available on Windows, we should also enable it there.

[NateAM]

@danielnachun Thanks for the review! I made the changes and using the local build utility they seem to work well. I've requested that you re-review.

[danielnachun]

I think we should consider splitting this into something like python-tardigrade_error_tools for the Python package and tardigrade_error_tools for the shared library, with python-tardigrade_error_tools depending on tardigrade_error_tools to provide the shared library. This would make it easier for end users who only need the C++ shared library to not have to depend on Python.

[kbrindley]

@danielnachun

I think we should consider splitting this into something like python-tardigrade_error_tools for the Python package and tardigrade_error_tools for the shared library, with python-tardigrade_error_tools depending on tardigrade_error_tools to provide the shared library. This would make it easier for end users who only need the C++ shared library to not have to depend on Python.

This may be a good long-term idea. In the short term, we don't have enough (or any) c++-only users to justify splitting the package like this. There is a larger stack of tardigrade_ prefixed libraries downstream of this package and all existing users will need both the c++ and Python together.

This is more obvious when we get to the more user-centric packages, e.g. #30248, where users will use the Python API to perform material model calibrations and then the c++ library to run finite element simulations against those same calibrations.