As announced earlier this month, every GitHub user now gets 120 free hours of Codespaces compute (GitHub’s hosted compute solution). That means you can get:
- 60 hours with a 2-core instance
- 30 hours with a 4-core instance
- 15 hours with 8 cores
- ~7 hours with 16 cores
The interesting thing here is that the 2-core instance is definitely enough for a week of sprinting and not run out of quota! Because of this, I would like to propose we make using Codespaces easy by adding the appropriate devcontainer configuration files to GitHub - python/cpython: The Python programming language .
First, a disclaimer: I do work for Microsoft on the VS Code team. That means I work for the company providing the free compute and on the team that defines the devcontainer spec. I do not work on Codespaces, but the VS Code team itself does work with them closely (not me personally, though). But I am doing this because I think it would be a benefit for us, not to sell anyone anything.
With that out of the way, what I’m proposing is that we (at least) add a devcontainer.json to the repo that specifies how to build a container to develop for CPython. The nice thing about doing this is we can make sure that contributors are set up from the start with the right tools to develop for CPython. This can even include setting up autoconf appropriately for even seasoned core developers. 
We can even get toolchains like for WebAssembly set up in the container so that even that is supported. The key thing here is it would let us make sure a Linux environment is always available that people can use to develop for Python without having to figure out what to install. And this works both locally via Docker or in Codespaces, so a potential win even for those not wanting to use hosted compute from GitHub. And the devcontainers.json can pretty much just point to a Dockerfile that we maintain, so there isn’t any vendor lock-in here.
After that we can consider setting up pre-builds for Codespaces. What that does is it re-builds the container image via a GitHub Action whenever we want; we can have it do it after every commit, once a day, whatever. But the key thing is we can make it such that building CPython from a pre-built devcontainer is extremely fast (if not instantaneous if we pre-build after every commit so there’s actually nothing to build until you edit the code). Much like making sure new contributors have the tools they need to build CPython with devcontainer.json, this would help facilitate new contributors by getting them going even faster and knowing that the build was already successful and usable.
Finally, and this might be the most controversial, we could configure the devcontainer for VS Code / https://vscode.dev . Since devcontainers can contain tool-specific settings we can add VS Code settings and extension recommendations so that folks have appropriate settings for things like indentation, etc. The only reason I’m suggesting this is that with https::/vscode.dev / https://github.dev it would allow folks to develop entirely via a browser during sprints using Codespaces, no local setup required. To be clear, though, this is not required and you can even use Codespaces with other editors like PyCharm. But as I said, this would let someone to show up with a Chromebook at a sprint and be able to get work done quickly.
So, what do people think? I know we have a general policy of not putting tool-specific stuff in the repo, but I think the benefits of all of this are great enough to consider at least the devcontainer.json bit and probably the pre-builds. Obviously I would love to also add the stuff to make using https://vscode.dev work, but I understand if people feel that’s too tool-specific.