Pre CEP: Package messages

[AntoinePrv]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

An way for package builder to display a message to end users.

Why is this needed?

There are many cases where packagers need to display a message to end-users:

• A non-open source conda package needs to tell their users that by using the package, they adhere to the end user license agreement, or that they need to specify a specific license key.
• Packages evolve and may split their assets into multiple packages (runtime, development...) and wish to inform downstream users.
• Packages need to inform that new package variants exist (without a clear best fit).
• Packages break their "conda" interface, e.g. they are renamed (see arrow-cpp > libarrow, or boost-cpp > libboost on conda-forge).

Currently, ways in which this is handled are:

• Write a message in activate.d, though this requires extra work and produces arbitrary code execution during activation. The package itself cannot distinguish if it is directly requested or not, which may produce additional noise for messages aimed at other maintainers.
• Handle messages in the project code itself when executed, though not all packagers are upstream contributors and some messages are not relevant for the whole project, just for conda. Also, it does not distinguish if the dependency is direct or not.
• Conda-forge runs migrations, though this is more complex and only available to the core maintainers. The migration information also does not get to regular users (not packagers) that may be using arrow-cpp directly.

What should happen?

In the package recipe.yaml, an extra set of keys is added, for example:

messages:
  - id: cf-libarrow-rename
    severity: warning
    indirect: false
    text: "The arrow-cpp package has been renamed libarrow"

These messages are collected along with package metadata and put in ${CONDA_PREFIX}/conda-meta/pkg.json and repodata.json (TBD).
The client displays them as they are configured, for instance:

• Selecting a relevant severity, possibly failing above a certain level
• Not showing messages marked indirect if the package is not directly requested by the user
• Using id to show messages only once per environment, and no longer in successive updates.

This is also easily programmable:

• Messages can be queried again, even after installation and outside of activation pipelines
• Conda-forge can decide to fail builds containing a specific warning

Additional Context

Open to discussion is if and how messages can be added to packages already built.
This could for instance be a way to attach CVE to existing packages.

[pavelzw]

sounds a bit like the "caveats" from the homebrew ecosystem