reactivate trilinos recipe

[rfiorella]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[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 (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

For recipe/meta.yaml:

• ℹ️ The boost-cpp output has been superseded by libboost-devel (as of 1.82), which now comes with a run-export (on libboost) as well. In case you only needed the boost headers, you should use libboost-headers.

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

[rfiorella]

Awaiting merge of updated kokkos-kernels feedstock, as macOS packages require dependency update

[rfiorella]

@conda-forge-admin, please restart ci

[conda-forge-admin]

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

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory. You can also examine the workflow logs for more detail.

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

[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 (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ requirements: host: kokkos == 4.2.01 should not contain a space between relational operator and the version, i.e. kokkos ==4.2.01
• ❌ requirements: host: kokkos-kernels == 4.2.01 should not contain a space between relational operator and the version, i.e. kokkos-kernels ==4.2.01
• ❌ requirements: run: kokkos == 4.2.01 should not contain a space between relational operator and the version, i.e. kokkos ==4.2.01
• ❌ requirements: run: kokkos-kernels == 4.2.01 should not contain a space between relational operator and the version, i.e. kokkos-kernels ==4.2.01

For recipe/meta.yaml:

• ℹ️ top-level output has some malformed specs:

• In section host: kokkos == 4.2.01, kokkos-kernels == 4.2.01
• In section run: kokkos == 4.2.01, kokkos-kernels == 4.2.01
  Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

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

[rfiorella]

@conda-forge/core ready to go! (ref #54).

Not the most recent release of trilinos, but there are a lot of deprecation notices in v16 and I figured it would be better to get a more recent version than is on conda-forge out sooner. I'll work to get it current in the next few months.

[h-vetinari]

This looks pretty good, thanks for stepping up!

[h-vetinari]

are you planning to update pytrilinos as well? See conda-forge/pytrilinos-feedstock#4 and discussion here

[rfiorella]

pytrilinos is one of the packages that's being deprecated for trilinos>16.1, in favor of pytrilinos2.

In principle I'm not opposed to doing so, but I probably won't get to it for another month or so, but curious if the upgrade to pytrilinos2 should just be done in the existing feedstock, or as a new recipe.

That said, there are multiple other packages that could be split this way from trilinos (e.g., Kokkos and Kokkos-kernels already have been, SEACAS could be (e.g., conda-forge/staged-recipes#30623) etc. I'm wondering if there is a preference to try to split out all of the potential TPLs from "meta-packages" like trilinos as their own recipe and just link to the other TPLs, or to have them more self contained? If the former, I could start to pick at this in spare time over the next several months.

[h-vetinari]

In general, we prefer to avoid monolithic monster packages, but rather splitting things up into relevant stand-alone components, at least where those have other uses/users (e.g. like kokkos).

pytrilinos is one of the packages that's being deprecated for trilinos>16.1, in favor of pytrilinos2.

I mean, is it just the name of the PyPI package or the python import name that changed? We could still provide a current pytrilinos on top of trilinos, and then add a "compatibility wrapper" for those people that somehow expect pytrilinos2, e.g.

outputs:
  - name: pytrilinos
    # [... the actual build ...]

  # compat wrapper for new package name
  - name: pytrilinos2
    requirements:
      host:
        - {{ pin_subpackage("pytrilinos") }}
      run:
        - {{ pin_subpackage("pytrilinos") }}

[rfiorella]

I'm not sure of the answer to your question, I'll have to look into it. The compatibility wrapper is a nice idea though, thanks!

[h-vetinari]

Could you add a comment why this needs to be pinned so tightly?

[rfiorella]

The short answer is that the build with both packages constrained to >=4.2.0, <5 failed because the version appears to be pinned pretty tightly within Trilinos cmake.

The previous recipe version built Kokkos and kokkos-kernels as part of trilinos, and I had been thinking it would be more space efficient to just link them but hadn't realized beforehand they were so tightly pinned within trilinos.

[h-vetinari]

OK, let's try this! 😅