Document support policy around external use of conda-forge-packaged compilers

[h-vetinari]

Where should the content be added?

Somewhere more user-visible than the maintainer docs?

What should be added?

In a recent core discussion, it came up that

@beckermr: [...] However, some folks do use our compilers outside of conda-forge and so it may be that they don't want [some conda-forge-internal thing]

I asked:

[...] Speaking of the compilers, how explicitly do we support use of them outside of our own ecosystem, beyond what we provide through the compilers package (which is heavily caveated)? Do we have anything on that written down somewhere?

Since it seems we don't have much that covers someone using (for example) gcc_linux-64 or clang_osx-64, and what expectations about continuity, stability, and lack of cf-internals users of such packages can make, I thought I'd open this issue.

I don't have a strong opinion either way, but I think we should document what we're willing to support (or not!).

Sidenote: support for our compiler stack (resp. lack thereof) is partially documented in src/maintainer/infrastructure.rst (though quite outdated), and the promises we make about this was a point of discussion in #1950

Additional information

No response

[rgommers]

However, some folks do use our compilers outside of conda-forge

I have always considered this a major and supported use case. For a couple of reasons:

• In the early days, when the compilers shipped in defaults and conda-forge weren't yet so mature, many folks (including myself) used system (e.g., Linux distro) provided compilers and everything else from a conda env. Folks like Jonathan Helmus made significant efforts to accommodate that, however they also consistently messaged that this was on a best-effort basis and by design was very difficult to make robust. And encouraged the use of compilers installed into conda envs as the better alternative.
• Many conda-forge maintainers and authors of conda and related tools like to talk about how conda-forge provides everything you need in terms of dev tools (even things that are perfectly fine to get from a distro instead, like git). Compilers are certainly an important part of any dev setup. And I've never seen anyone recommend the opposite (don't use compilers from conda-forge, but take them from your system).

From my perspective, the framing here is a little strange. I'd say that conda envs used for regular development on some Python package or application have a much larger audience than using conda envs for building conda-forge packages. In addition, the smaller group of packagers is much better prepared to take an extra preparation step needed for package building and be up-to-date on the recommended ways of doing things. Hence what I'd expect is:

• When one installs compilers, they are set up well for local development in a conda env (e.g., no CFLAGS et al. pollution, xref Flags in compiler activation vs. out-of-conda-forge usage #2002),
• When one wants to build a package for conda-forge locally, there is some extra step to take - or conda-build takes that step automatically.

and so it may be that they don't want [some conda-forge-internal thing]

+1. I think any conda-forge-internal-only thing should be opt-in and explicitly enabled.

[jakirkham]

It's worth noting that in CUDA 12, the CUDA compiler follows a similar structure