Add devcontainer specification to improve developer experience

[tjarbo]

Hi,
in order to simplify the onboarding of new contributors to the project, I would like to contribute a devcontainer specification for pretalx plugins. Testing it here first before submitting it to the plugin template/other plugins.

Development Containers or "devcontainers" is an open specification mostly driven by Microsoft, allowing maintainers or contributors to easily spin up a predefined unified development environment based on common local container runtimes like podman or docker. The execution of project related preparations steps are fully automated (except for the "init" command, but this can be also automated once the necessary interface is in place.), so that the necessary steps, once podman and e.g. VS Code with the Remote Development Ext. is installed, to get started as a new contributor are reduced to:

1. Clone the project
2. Open folder in VS Code.
3. Run the "Dev Containers: Reopen in Container".

Best regards

[rixx]

Thank you for this! That’s a pretty cool idea – however, I’m a bit concerned about the maintenance burden.

I’m personally not a user of VS code or containers, so I wouldn’t notice when this configuration has to change or breaks, and referring to a setup like this, but breaking it, would probably make the developer experience worse rather than better.
Add the multitude of plugins out there, and an outdated config could get painful pretty fast – e.g. once Python 3.12 is outdated, we’d need to touch all the Containerfile files.

That’s not a veto on the PR, just thinking out loud and hoping for feedback.

[tjarbo]

I can totally understand your concerns. There are multiple ways we can solve these. In general, I can only recommend using tools like the renovate bot (which can be even "self-hosted") or GitHub's Dependabot to automatically prepare dependency-update PRs. These can even cover Containerfile files and their referenced base images. But you mentioned the issue of scaling with this approach if applied to more and more repositories.

Therefore, based on the idea that even today you are maintaining already a centralized development documentation, I can imagine that for pretalx it could be worth to provide a standardized container image for development containers (both pretalx itself and for plugin development), including default installation scripts (which can be then overwritten on an individual basis if needed) or e.g. all needed dependencies. While the general devcontainer-spec cannot be shared between multiple projects with ease, the container image can. This will reduce the maintenance overhead to a single repository, similar to your documentation, and the community can easily provide updates in cases of issues. The devcontainers should not replace the current development approach, but instead provide a simplified alternative.

If interested, I can prepare a PoC as a personal repository that could be then transferred to pretalx if confirmed.

---

You are not using containers? Uh, I can highly recommend to give it a try ;) The dev-container spec is not limited to VS Code itself, but also supported by other IDEs like JetBrains' products.

[rixx]

Hm, would Renovate cover changes to the file format or similar bigger issues? Those are my real concern: As I do not use the format, I wouldn’t even notice when it falls into disrepair.

I can imagine that for pretalx it could be worth to provide a standardized container image for development containers

Define “worth” – maintaining and developing pretalx and most of its plugins all on my own is already a ton of work. Adding maintenance burdens like that is something I am very wary to undertake, especially given the relatively low number of external contributors. (I see an obvious point to be made here about making the project inviting to contributors so that there will be more of them. It’s all trade-offs.)

However! I still really like the idea, and

If interested, I can prepare a PoC as a personal repository that could be then transferred to pretalx if confirmed.

This sounds like a great way forward. I'd be happy to link to your repo + docs from plugin pages and also from the official developer documentation, so that it’s discoverable to newcomers!

You are not using containers? Uh, I can highly recommend to give it a try

I have honestly never felt that I am missing something – and on the flipside, I have often cursed the need to learn yet another specification format just to tell a process to run Python and connect to a database. Any layer between me and the debugger feels like one too many. (I don’t use an IDE either, strictly speaking, so I feel like the advantage would be really fairly minimal …)