Add devcontainer definition

[deen13]

Short description

This Pull Request adds a devcontainer definition to make the project setup easier and streamline the onboarding process of new devs.

Proposed changes

I encountered some difficulties during onboarding and initial setup of the project, which I aim to automate with this addition. Through discussions in the chat, I learned that most people here develop with VSCode, so I thought that a devcontainer would be the appropriate solution.

Challenges Encountered:

• Initially, I installed a too-new patch of Python 3.11, which caused some issues and required downgrading.
• The translate.sh script expects the GNU variant of sed, which needs to be installed separately on macOS. Additionally, it needs to be either changed in the script to gsed instead of sed or overridden with an alias. The base image of the devcontainer includes the correct sed directly.
• The project requires the programs gettext and libmagic as native dependencies, which are also included in the base image of the devcontainer.
• After starting the project for the first time, I couldn't log in because the database was still empty. The devcontainer automatically loads the test data.

Side effects

There should be no major side effects besides that we might need to take care of both the nix-flake (#2730) and the devcontainer definition.

Optimizations

The Docker image built for running the devcontainer is currently quite large, at 2.1 GB, and it contains a nested Docker installation. I propose we create our own Dockerfile that utilizes a native PostgreSQL setup and implementing image caching if this feature is utilized by a significant number of users.

---

Pull Request Review Guidelines

[codeclimate[bot]]

Code Climate has analyzed commit 402a06a3 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 81.8% (0.0% change).

View more on Code Climate.

[deen13]

Just learned that .devcontainers are now also supported by Jetbrains Gateway, so this is not only for the VSCode folks. 🥳

https://youtrack.jetbrains.com/issue/IDEA-292050/Support-for-.devcontainer#focus=Comments-27-9448589.0-0

[charludo]

I didn't check out the other PR yet, but does it essentially tackle the same problems? If so, I'd suggest taking a vote in the team for the preferred solution and only provide one default dev setup which works independently of the user's OS. Having multiple "supported" options to setup the dev environment might not make onboarding easier in the future.

I'd like to chhime in here, because yes, both solutions solve the same problem, just in a different way. I'm not sure if maintaining both isn't still an option though: For people using JetBrains or VSCode, the devcontainer setup might be easiest to get running, while the nix shell requires one additional dependency (nix itself) but is editor-agnostic. It should definitely be mentioned in the README though, that one or the other way can be chosen depending on one's current setup.

That said, I think most of your challenges could just be solved by a docker compose setup, not necessarily a .devcontainer setup.

TBF getting to rid my system of docker is one of the main benefits of the flake/devcontainer route (at least to me) 😅

[deen13]

Hey @timobrembeck,

I brought up the topic in our weekly call and we reached a consensus to maintain both versions. It's worth noting that limiting ourselves to just one solution wouldn't necessarily simplify matters, as developers tend to configure their environments locally according to their preferences anyway. By retaining both options, we acknowledge this tendency and ensure that developers can still tailor their setups while also benefiting from shared solutions. Additionally, these solutions cater to different user groups; some may prefer more integrated tooling like devcontainers, while others feel more comfortable with an editor-agnostic setup in their ide.

[charludo]

Well said @deen13. One thing I'd like to add: I can see an maintainence-effort argument against keeping both solutions, but the maintainence required should be minimal, since in both cases only the environment required to run the project is defined, the single source of truth for all python/node packages remains with the existing config files.

[deen13]

VSCode marked all non-project imports as unable to find them; probably related to the move back to the venv?

Good catch @charludo! I fixed the defaultInterperterPath in 235a415