Isuru Fernando

Since we don't have osx-arm64, it's critical that we keep building for osx-64. Even if we don't build for osx-64 for pytorch, the downstreams will need a `osx-64` pytorch to...

Sure. Here's a list - test coverage must remain the same or improve for at least one macos platform. - ability to building downstreams for osx-arm64 must not decrease. Your...

Since there's already `gcc, gxx, gfortran` in this feedstock that does the minimal thing, I don't see the need to add another output here. So, I suggest you raise this...

Or in the conda-forge.github.io repo where you can talk about the entire compiler stack.

IMO, relying on activation scripts is the wrong solution for letting our compilers be used by users outside of conda-build. This is because we want the compilers to work in...

> I think this is a nice idea, and the proposed implementation sounds like a good compromise. @mgorny thank you for your input. Which idea in particular are you talking...

> I was talking about the original idea from #c0, i.e. splitting off conda-forge specific activation. Even if we long term don't want people relying on activation scripts, they already...

The convenience output is something that is needed rarely, so I don't want to bikeshed on the name and spend a lot of time on this.

> There's quite a bit of interest in this from various parties. No, the interest is to use the ones with the `cfg` or `specs` files. There's very little interest...

1 & 2: `gcc-no-specs` this is misleading because there's already a spec file and the conda spec file is additional. 3: `conda-forge` is bad since there's a `defaults::conda-gcc-specs` and having...