jaimergp

xref https://github.com/conda-incubator/setup-miniconda/pull/364

Fiiine: #82. Just started by copying over the existing docstrings and making it a bit more consistent.

It looks good but I think we would need to generate a license report like they are doing in https://github.com/conda-forge/junit5-feedstock/blob/02d3543758a9d40a03232ac6056642ff81a44ca6/recipe/build.sh#L15?

Cool, I'll update the status page!

Hm, I'm not sure about this. The `is_base` bits were implemented to maintain feature parity with `menuinst 1.x`, but I was never a fan. Assuming you control the installer generation...

In the future, `base` is going to be a protected environment and apps will be recommended to ship a "default" env with their software, leaving `conda` in `base` (and nothing...

Fair enough. Also, I think you could accomplish the same with a single package, but two build variants, with some `sed` replacement similar to [what we do in the napari...

We would need to accommodate for [`remote_ci_setup`](https://github.com/conda-forge/conda-smithy/blob/2b7cbe342e3d12929eee0aea8a7bdf1389a0142f/conda_smithy/schema.py#L906-L922), which allows to modify the `base` environment. So `conda-smithy` would need to encode something like this: ```yaml {% for pkg in remote_ci_setup %}...

> An alternative could also be to create an installer that already contains the base installation and use that instead of Miniforge. I've been thinking about this for a bit...

From our core call today, the two items we seem to be tackling here are: - Reducing the overheads of provisioning the build tool (conda-build, rattler-build) and the related tools...