Provide a Container-based Development Environment for Contributors

[digitalentity]

As the title says.

Would help avoid build environment issues like #179

[vorburger]

@digitalentity let's scope this better... are you interested in / suggesting:

A. Having a container image built in CI and pushed to the ghcr.io to make it trivial to do (something like) docker run --rm -it ghcr.io/enola to make it much easier to use enola than it is right now, without end-user having to set up a development environment? That is a great idea, and something which I'm all for, open to contributions about, or otherwise eventually hope to do myself. I see this being implemented by a hopefully relatively simple additional step in the existing GitHub Action which copies what is needed into a container and pushes it to a registry (and without converting the well working rest of the existing infrastructure into having to run only in a container). Any contributions to make that happen would be super welcome!

B. Having a container image to simplify local development set-up? That is something I am personally very reluctant to get into and having to support. For some context and background: I have come "full circle" on that approach... A few years ago I would tell anyone who would listen that this is the greatest idea since life spread, and should be imposed on any project. In https://github.com/OASIS-learn-study/minecraft-storeys-maker I pushed this quite far (together with @edewit) and we have build and test and runtime server containers and what not. The trouble is... there is quite a bit of work to maintain that, make it work "half of your shit inside the container and the other half outside" - mounting sources, various caches from the several different build tool technologies which I am using in this project, having build tools dig correctly caching in- (pre-distributed tools) and out- (sources, build caches) of the container, all the fun that container image caching layers can be and when and how they need to be rebuilt, etc. The "value" is "just" reducing friction for a few developers. It's possibly more worthwhile solving the related problems with a really large developer community, but in general, with modern build tools, which download all of their dependencies, and automatically update them (only) when versions in certain files change - this IMHO is often not actually the right approach. I'm therefore currently quite reluctant to pursue that for this project.

[digitalentity]

It's the (B) option, really, after banging my head against the wall trying to get it to build for O(hours).

I agree that if a developer is using a set of common tools & common toolchain for all of the projects setting up a new one is a no-brainer. Same is true for setting up a dev environment on a clean system.

However, for a developer working on multiple different projects when each of them uses different toolchains and often requiring a different set of system dependencies, not having an isolated dev environments often becomes a show-stopper for contributing. This is especially true for cross-compiled software, that's why I started bundling the build environment with my projects and my only dependency is typically make - the rest is part of the repo itself.

As you are a BDFL of this project the call is obviously yours 😆

[vorburger]

I don't want to completely shut the door either, and am open to reviewing a contribution for this, if you are motivated enough to put in the work - and maintain it and offer future support for it... that's the B of a BDFL! 😸

[vorburger]

The (A) option has just been implemented, see #396 and https://docs.enola.dev/use#container.

Keeping this issue open for possibly doing (B) one day.

[vorburger]

Keeping this issue open for possibly doing (B) one day.

I'm now more interested in this... 😄

The primary reason is that I'm finding GitHub Codespaces doesn't seem to work well - very slow, I'm not sure why.

https://cloud.google.com/workstations would be fun, but as-is don't "just work" out of the box, either.

Even without neither GitHub Codespaces nor GCP Workstations, this would be nice for local dev.

I'm torn whether to bet fully on https://containers.dev or not (given I would need to fix #435 for myself, first)...

...or if that's "not required" (or likely just "complementary" - a minimal devcontainer.json could still be used, but with an Dev. Env. image built by this project - instead of (something like) the mcr.microsoft.com/devcontainers/universal:2-linux (which is currently used).

What I haven't quite gotten my head around yet is how a VSC locally, or on a GCP Workstations, without Dev Containers support, would use it. I need to do some more reading up on how folks typically do this... (And as an aside, how would would one then "mix" their "personal" dotfiles dev. env. with a "project's (such as this) required tools" container?

I guess before worrying about IDE integration perhaps a first simple goal could just to enable a local build, via container...

@digitalentity are you interested in chatting further about this by voice some time?

@teivah is this perhaps the kind of thing you enjoy dabbling with?

[vorburger]

#454 made a start for this, see https://docs.enola.dev/dev/setup/.

But there's probably more work required to make this truly convenient? Reading TODO:

• https://code.visualstudio.com/docs/devcontainers/containers
• https://code.visualstudio.com/docs/devcontainers/create-dev-container
• https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user