Dev Container Feature for Haskell

[bamurtaugh]

Hi there 👋! I'm a Product Manager on the VS Code team at Microsoft and a maintainer of the open Dev Container Specification (https://containers.dev/). A Development Container (or Dev Container for short) allows you to use a container as a full-featured development environment.

To help developers configure environments with everything they need, they can use or create Features, which are self-contained, shareable units of installation code and dev container configuration.

We've had interest for a Haskell dev container Feature: devcontainers/features#470. We'd love to know if hosting a Haskell Feature is something the Haskell maintainers might be interested in. If so, we're happy to collaborate with you on any questions and feedback throughout the process. @brendandburns who opened the great Haskell Feature PR linked above can contribute it to one of the Haskell repos if you're interested.

Thanks so much!

[Bodigrim]

Hey @bamurtaugh, thanks for reaching out!

We'd love to know if hosting a Haskell Feature is something the Haskell maintainers might be interested in.

Could you please elaborate what exactly does "hosting" entail in this context? Is it just about granting a repo under https://github.com/haskell? Is it a usual practice in other language communities?

CC @hasufell, who knows about VS Code integration infinitely more than me.

[hasufell]

Hi, I'm maintaining GHCup Haskell installer and the vscode-haskell extension (with @fendor).

This sounds like a great idea. I left a couple of comments on the PR: devcontainers/features#470

Note that the vscode-haskell extension does not need a full toolchain pre-installed, just the ghcup binary.

Let me know how I can help.

[jcbhmr]

Some other examples of communities hosting their own devcontainer features are:

• https://github.com/mamba-org/devcontainer-features
• https://github.com/JuliaLang/devcontainer-features
• https://github.com/rocker-org/devcontainer-features

From https://containers.dev/collections

cc @Bodigrim @eitsupi

[Bodigrim]

I'm fine with providing https://github.com/haskell/devcontainer-features or similar, if that's the only thing required from our side.

[bamurtaugh]

Thanks so much for the interest and discussion so far!

I'm fine with providing https://github.com/haskell/devcontainer-features or similar, if that's the only thing required from our side.

Yes, providing a repo like that would be a key part here.

Along with hosting the code in a GitHub repo like the one you mention, hosting a Feature also involves publishing the Feature to an OCI registry, like ghcr. We have a quick getting started repo that provides a GH Action to help, along with more in-depth info in the spec.

In our community index, you can see each entry has on oci reference (example).

Please let me know if you have any questions or thoughts.

cc @samruddhikhandale @joshspicer in case I missed anything :)

[Bodigrim]

hosting a Feature also involves publishing the Feature to an OCI registry, like ghcr. We have a quick getting started repo that provides a GH Action to help, along with more in-depth info in the spec.

I'm afraid that's above my pay grade ;) Could @brendandburns as the original author do this?

[bamurtaugh]

I think it makes the most sense (access-wise and process-wise) for the registry to be driven by someone fully within the Haskell org. I understand if that's not feasible, in which case we'll likely merge the PR within the devcontainers/features repo.

[Bodigrim]

Thanks for clarification, I'd suggest merging within the devcontainers/features repo then.

[ulysses4ever]

We'd probably have a better turn around in a separate repository. My very brief glance at how things worked in the main devcontainers repo before makes me think that sometimes it's an issue.

[Bodigrim]

@ulysses4ever do you have a bandwidth to own it?

[ulysses4ever]

@Bodigrim I can be a janitor, yes, but I'd need a co-owner with better expertise. So if, for instance, @brendandburns would agree to participate, that would be ideal.

[hasufell]

I don't mind co-maintaining it.

[Bodigrim]

Great! @ulysses4ever and @hasufell, please take a lead on this. @hasufell has enough rights to create a new repository in our namespace.

[bamurtaugh]

Hi folks! I just wanted to check on the latest here - if there are any questions/topics I could help with, please just let me know. Thank you!

[ulysses4ever]

@bamurtaugh thanks for checking in! We're stuck until @brendandburns voices an opinion, I'm afraid. Or some other volunteer pops up to champion this effort.

@Bodigrim @hasufell maybe we should issue a call for volunteers on Discourse/Reddit/Cafe?

[Bodigrim]

Indeed my understanding is that this awaits for @brendandburns to opine, whether he is interested to move his work under github.com/haskell or suggest other directions.

@ulysses4ever feel free to proceed as you see fit.

[bamurtaugh]

We're stuck until @brendandburns voices an opinion, I'm afraid. Or some other volunteer pops up to champion this effort.

Ah got it, I misunderstood and thought some folks here were okay with initiating and being the co-maintainers moving forward. Thanks for the clarity!

Indeed my understanding is that this awaits for @brendandburns to opine, whether he is interested to move his work under github.com/haskell or suggest other directions.

If the remaining question is if it's okay to move the work here (and folks are already okay with moving it forward), I chatted with @brendandburns a few weeks ago, and he was happy to move the content to the Haskell org. Though I believe we were both thinking the Haskell community would then lead and maintain it from this point on.

Please let me know if you do find another community maintainer who would be interested in championing this, otherwise I think we'll proceed with the existing devcontainers/features PR https://github.com/devcontainers/features. cc @samruddhikhandale for awareness as an original reviewer of the devcontainers/features PR.

[ulysses4ever]

@bamurtaugh maybe merging that PR would be more appropriate short-term. There's just not enough cycles for moving it forward on our side, I feel.

[ulysses4ever]

There's a devcontainer for musl-based build of GHC: https://github.com/benz0li/ghc-musl

[benz0li]

There's a devcontainer for musl-based build of GHC: https://github.com/benz0li/ghc-musl

The GHC musl repository also provides general purpose Dev Containers.
ℹ️ For further information, see GHC musl: Dev Containers.

---

👉 Stack uses

1. the GHC musl image¹ to build its statically linked Linux amd64 and arm64 binary releases and
2. an adapted version of GHC musl's Dev Container to provide a full‑featured dev environment.

ℹ️ For further information, see https://docs.haskellstack.org/en/stable/dev_containers.

---

Cross reference: https://discourse.haskell.org/t/dev-containers-added-to-stack-repository/7604

Footnotes

1. Multi‑arch (linux/amd64, linux/arm64/v8) ↩

[benz0li]

Please note the following about my GHC musl images:

They contain unofficial binary distributions¹ of GHC (that is, ones not released by the GHC developers). That is because:

1. the official GHC binary distributions for Alpine Linux/x86_64 have known bugs; and
2. there are no official binary distributions for Alpine Linux/AArch64.

Regarding the official binary distributions for Alpine Linux/AArch64: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10594#note_531186

There may never be a fully statically linked GHC bindist, though: https://gitlab.haskell.org/ghc/ghc/-/issues/24044#note_529407

Footnotes

1. Built using the LLVM backend; flavour: perf+llvm+split_sections ↩