This adds Dev Container support, with some VS Code-specific extensions defined. Also updated the .gitignore to exclude macOS system files, and VS Code workspace files.
This came about for my desire to develop on my Mac, without interfering with my personal machine environment.
Here's some background and reasoning:
Dev Containers are an IDE-agnostic open specification (originally created by Microsoft/GitHub) that define a container environment to use for development.
This is especially useful for separating development environment configuration from the host system (not polluting PATH, environment variables or registry entries, maintaining installation of multiple versions of JDK or Python, etc.) as well as allowing new developers to get up-and-running with all the dependencies that are needed to contribute to the project.
Using one devcontainer.json and an optional Dockerfile, this is easily accomplished. Any IDE that supports this feature (VS Code, GitHub Codespaces, IntelliJ products, others) will read this file and spin-up the container through a Docker daemon running on Docker Engine, or alternatively, a 3rd-party container engine.
The advantage of Dev Containers and devcontainer.json over just running a container separately, is that the IDE is aware of the container and connect to it as a remote host in a session for development, and also allows for specification of IDE-specific extensions to be used in that development environment as well.
After downloading the initial image and configuring the environment (a couple of minutes), it's lightning fast (a couple of seconds) to start for any development session, even if the devcontainer.json or Dockerfile is changed and the container needs to be rebuilt.
In the IDE or through a terminal connection to the container, the project can be built, run, and tested without issue.
Perhaps best of all, it's just two new files in a hidden directory, which doesn't require anyone to use them if not desired
Caveats:
While the project can be built, run, and tested in the container, I haven't tested if the resulting binary will "work" outside of the running container in macOS, but is unlikely as it is built by make/qmake in a Debian container... Until macOS containers are a thing (or able to set a build target via command line when calling qmake), this workflow likely will not be possible. This could work if running on a Debian system after building/installing in a Debian container, etc.
dependabot.yml was automatically added, which will keep Dev Container "Features" updated, and can be deleted to opt-out if not desired: https://containers.dev/guide/dependabot
This adds Dev Container support, with some VS Code-specific extensions defined. Also updated the
.gitignore
to exclude macOS system files, and VS Code workspace files.This came about for my desire to develop on my Mac, without interfering with my personal machine environment.
Here's some background and reasoning:
Dev Containers are an IDE-agnostic open specification (originally created by Microsoft/GitHub) that define a container environment to use for development.
This is especially useful for separating development environment configuration from the host system (not polluting
PATH
, environment variables or registry entries, maintaining installation of multiple versions of JDK or Python, etc.) as well as allowing new developers to get up-and-running with all the dependencies that are needed to contribute to the project.Using one
devcontainer.json
and an optionalDockerfile
, this is easily accomplished. Any IDE that supports this feature (VS Code, GitHub Codespaces, IntelliJ products, others) will read this file and spin-up the container through a Docker daemon running on Docker Engine, or alternatively, a 3rd-party container engine.The advantage of Dev Containers and
devcontainer.json
over just running a container separately, is that the IDE is aware of the container and connect to it as a remote host in a session for development, and also allows for specification of IDE-specific extensions to be used in that development environment as well.After downloading the initial image and configuring the environment (a couple of minutes), it's lightning fast (a couple of seconds) to start for any development session, even if the
devcontainer.json
or Dockerfile is changed and the container needs to be rebuilt.In the IDE or through a terminal connection to the container, the project can be built, run, and tested without issue.
Perhaps best of all, it's just two new files in a hidden directory, which doesn't require anyone to use them if not desired
Caveats:
make
/qmake
in a Debian container... Until macOS containers are a thing (or able to set a build target via command line when callingqmake
), this workflow likely will not be possible. This could work if running on a Debian system after building/installing in a Debian container, etc.dependabot.yml
was automatically added, which will keep Dev Container "Features" updated, and can be deleted to opt-out if not desired: https://containers.dev/guide/dependabot