No dependency on ICU for the static build

[JohanMabille]

As suggested in mamba-org/mamba#4355 (comment), we should build libpsl-static without depending on ICU. For now only micromamba indirecly depends on it (through libcurl, which does not use libpsl for IDNA / unicode support), so it is safe to build without ICU. If we need it in the future, we may want to build a variant since ICU is a heavy dependency.

[JohanMabille]

@conda-forge-admin please rerender

[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 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.

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

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

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

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

Here's what I've got...

For recipe/recipe.yaml:

• ❌ There are 1 too many lines. There should be one empty line at the end of the file.

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

[JohanMabille]

@tschoonj this is ready for review.

[isuruf]

Why do you need a run_exports for the static library?

[JohanMabille]

Because the headers are in the libpsl package, and there is no "host_export" feature in the conda ecosystem.. Not doing so would require any downstream package depending on libpsl-static to also depend on libpsl.

[isuruf]

You are conflating run vs run_exports.

[JohanMabille]

So we should add libpsl in the host section of packages depending on libpsl-static at build time (to get the headers), and ignore its run_exports (in order no to pull libpsl when installing a package depending on libpsl-static) ?

[JohanMabille]

Ah got it, sorry for the confusion.