Dev Container

[korverdev]

I was curious if the maintainers of this project have given any thought to using dev containers to simplify getting a development environment setup. I've been using this for a couple of projects I work on and the experience has been great, especially for getting new contributors set up quickly. I'd be happy to work on this, but I wanted to gauge interest before putting this together.

[DimitriPapadopoulos]

What would a dev container look like? Right now, you “just” need to:

• install Python,
• run pip install -e ".[dev]".

[korverdev]

@DimitriPapadopoulos That is likely. Codespell doesn't have many requirements, so it would be a relatively simple config file. The nice thing with dev containers is the integration with VSCode and a few other editors that allows you to setup a consistent, containerized development environment in one button click. It's definitely not a need, but I've found them very helpful when juggling multiple development environments between projects.

[DimitriPapadopoulos]

I must admit my ignorance, I don't know what a “dev container” for IDEs looks like. Is the expected format standard?

Should it be maintained in this repository, or perhaps a new repository under https://github.com/codespell-project? How do other projects manage that?

[korverdev]

Apologies. I probably should've explained the technology more. Dev containers are an open standard Microsoft put together. It's effectively just a JSON file that describes a standard Docker development environment and would live in the Codespell repository. Here's an example.

Currently, this is used by GitHub Codespaces, which is GitHub's cloud development solution. VSCode has a first-party extension for this. There's also a CLI and support has been or is being added to quite a few other code editors.

[DimitriPapadopoulos]

So this would just involve adding a small .devcontainer/devcontainer.json file, wouldn't it?

@larsoner Would you agree to add such a file?

[korverdev]

That is correct. Unless you actively use dev containers, it'll just mean one more config file in the repo and wouldn't impact current local development setups. Wanted to run this by you first since this is a somewhat opinionated technology, but if y'all are open to this, I'd be happy to set this up. I find it extremely useful as a sort of venv alternative.

[larsoner]

Having one more file to maintain has a cost, but if it can automatically pull in deps and such (e.g., using pip install .[dev] or whatever inside the container) it sounds painless enough. So +1 from me