Feature: Add devcontainer configuration

[kenibrewer]

Checklist

• [x] Used a personal fork of the feedstock to propose changes

Description

Adds a devcontainer configuration that installs conda-smithy and docker-in-docker (for local build testing).

[conda-forge-webservices[bot]]

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) and found it was in an excellent condition.

[hmaarrfk]

Why is

conda debug -m .ci_support/linux.... recipe

or

python build-locally.py --debug

not enough?

[kenibrewer]

@hmaarrfk The purpose of the devcontainer configuration is precisely to enable running the two commands you listed in a completely isolated development environment. You make no assumptions about any pre-installed software (e.g. conda or conda-smithy) the developer is likely to have on their machine and instead provide a configuration that installs everything for them.

I find this particularly useful because it's compatible with Github Codespaces which allows you to shift your development environment into the cloud as well.

If you want to take it for a spin, go to this link to create a Codespace using the devcontainer configuration in this branch. Despite the failing CI pipelines (related to the recipe) the devcontainer is working correctly.

[hmaarrfk]

does all this run on the GitHub cloud? if so. that is pretty interesting.

let's discuss this feature outside of this feedstocks. this kind of tooling should be automatically generated by conda smithy and not added in an adhoc fashion. ya least in my opinion.

conda forge tends to suck up public resources and I'm somewhat worried we would damage the goodwill of Microsoft (Azure, and recently Github) where we build most of the packages

[kenibrewer]

does all this run on the GitHub cloud? if so. that is pretty interesting.

A devcontainer.json configuration can be used in two ways:

1. Locally in Docker via VSCode DevContainers - this relies on no cloud infrastructure
2. In the cloud on Github's Codespaces servers. - This is a paid service, but each Github account has a certain amount (~40 hours IIRC) of free usage per month.

let's discuss this feature outside of this feedstocks. this kind of tooling should be automatically generated by conda smithy and not added in an adhoc fashion. ya least in my opinion.

I'm new to contributing conda-smithy and the feedstocks. My intuition was that adding some convenience functions to aid maintainers in debugging their failed recipes would be allowable. But if you think this would be better to add directly to the templates, I'd be happy to open a feature request and a PR at conda-smithy. Would this be the correct place to add that?.

conda forge tends to suck up public resources and I'm somewhat worried we would damage the goodwill of Microsoft (Azure, and recently Github) where we build most of the packages

I don't think this is a concern when hands-on developer time is probably a tiny fraction of what the automated actions workflows consume. Also, the codespaces usage is tracked/billed for each individual developer and using the local docker option uses no cloud resources.

[hmaarrfk]

I unfortunately I think we should try to limit "customization" like this.

You have a few options:

1. Create a pinned issue to help you debug
2. use the commands i listed above
3. make a case for it in github.com/conda-forge/conda-smithy

Do take into account the discussion in: https://github.com/conda-forge/conda-smithy/pull/1413

where effectively some are considering ignoring everything outside the recipe folder.

While I am but 1 core developer I think that the commands:

conda debug
python build-locally --debug

will just really be enough for 99% of the packages.

adding too many layers of abstractions really hurts development sometimes.

[kenibrewer]

Thanks for the explanation @hmaarrfk . I'll make the appropriate feature request in conda-smithy.