Nothing substantive, but I can report that it worked! 🎉

The conda package search and package resolution was pretty slow and creating the initial image took about 5 minutes. But after that restoring the codespace after stopping it was fast enough.

I was curious about codespaces because it might be useful for Astropy as well. Looking forward to the tutorial and sharing ideas.

@taldcroft feel free to reach out with questions and comments. Our discussion boards, and my calendar, are available.

I had a look at this, a few comments:

• This overall looks quite maintainable, which is great
• Startup time is ~5 minutes, mostly due to conda resolving our dev environment slowly. Hopefully a base image update will solve this sometime soon (with conda 22.11 we can enable the libmamba solver). xref DEV: Fix shell configuration in devcontainer #23076 (comment)
  • Restarting is more like 15 seconds, which is great.
  • Pulling in libmamba will perhaps also solve the issue noted in devcontainer.json about needing at least 8 GB. This makes 2-core instances unavailable - it's pretty bad that we need to use minimum 4 cores (hence doubling the cost or halving the available free dev time for contributors) just because of conda.
  • After writing the above: using micromamba works, and reduces startup time to <2 min. I'll open a PR.
• Fonts are wonky in the editor and terminal, in particular with numbers. Example screenshot below.
• The numpy-dev conda environment isn't activated when the container starts. I tried to add it in devcontainer.json, but that fails the container build. It would be useful to at least echo a message like "Welcome! Please activate your development environment with conda activate numpy-dev" to the terminal so this doesn't confuse new users.
• I think not building numpy itself as part of the container build is a good idea. This keeps things simple; users should be able to follow the contributing guide pretty easily, everything they need is installed already.
• It seems like we're missing a few IDE things, e.g. no code highlighting for .toml and meson.build files.

One thing that I remembered now so that it doesn't get lost: I could build the docs just fine, but couldn't figure out how to open the generated static html.
There is hopefully a simple step I just didn't know, but it would be good to include it in some docs (and/or in a quickstart during startup).

@seberg if you have the Live Preview extension installed in vscode you can do that by right clicking the built html file and then selecting "Open in external browser" (wording may be slightly off but the option is there)

Thank you all for the valuable feedback! I am really happy to see the addition of micromamba to the configuration. One option for scaling its installation and maintenance for yourselves and for others is to implement it as a dev container feature [1].

Regarding fonts, those are completely configurable in VS Code [2]. If you want the fonts to be a default that are shared across all users, you can configure those in the dev container by adding customizations in the devcontainer.json [3]:

  "customizations": {
      "vscode": {
        "settings": {
          "terminal.integrated.shell.linux": "/bin/bash",
          "python.pythonPath": "/usr/local/bin/python",
          "editor.fontFamily": "'DejaVu Sans Mono for Powerline'",
          "terminal.integrated.fontFamily": "'Hack NF'"
        },
        "extensions": [
          "be5invis.toml",
          "mesonbuild.mesonbuild",
          "ms-vscode.live-server"
        ],
   }

Individual users can override those defaults with their own preferences either temporarily by updating those settings, or more permanently with setting sync or using dotfiles [4].

To instruct users to initialize their conda environments, you can follow the pattern in this devcontainer [5].

     "onCreateCommand": "sudo cp .devcontainer/welcome-message.txt /usr/local/etc/vscode-dev-containers/first-run-notice.txt",

For toml support in VS Code you could include an extension in your dev container. The VS Code marketplace has several to choose from [6]. There's also a Meson extension [7].

And as @melissawm pointed out, the Live Preview extension [8] can help you view static files.

Thanks again for all the feedback. I'd love ideas for making these things easier.

1. https://containers.dev/implementors/features-distribution/
2. https://code.visualstudio.com/docs/terminal/appearance
3. https://containers.dev/supporting#visual-studio-code
4. https://docs.github.com/en/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account
5. https://github.com/ngrx/platform/tree/master/.devcontainer
6. https://marketplace.visualstudio.com/search?term=toml&target=VSCode&category=Programming%20Languages&sortBy=Relevance
7. https://marketplace.visualstudio.com/items?itemName=mesonbuild.mesonbuild
8. https://marketplace.visualstudio.com/items?itemName=ms-vscode.live-server

Thank you all for the valuable feedback! I am really happy to see the addition of micromamba to the configuration. One option for scaling its installation and maintenance for yourselves and for others is to implement it as a dev container feature

Thanks or the suggestion @craiglpeters. I actually tried that, but it wasn't any faster and harder to read, so I decided to stay with the setup.sh edits.

If you want the fonts to be a default that are shared across all users

We can do that, but isn't the Codespaces default worth fixing here? What you see in the screenshot above is so bad that I'd say it should be considered broken.

To instruct users to initialize their conda environments

Thanks, I'll try that - either do the activation or add a message (or both).

Thank you all for the valuable feedback! I am really happy to see the addition of micromamba to the configuration. One option for scaling its installation and maintenance for yourselves and for others is to implement it as a dev container feature

Thanks or the suggestion @craiglpeters. I actually tried that, but it wasn't any faster and harder to read, so I decided to stay with the setup.sh edits.

Fair enough. Since the install is simple keeping it there is fine. IF you ever decide to work with Codespaces Prebuilds [1] a feature would benefit you because they can be installed once, and the resulting file system is reconstructed from the prebuild which can speed things up in some cases (e.g. long installations or large repository clones).

If you want the fonts to be a default that are shared across all users

We can do that, but isn't the Codespaces default worth fixing here? What you see in the screenshot above is so bad that I'd say it should be considered broken.

VS Code has some default settings that work well in some cases, and poorly in others. Your system may have some settings that affect how VS Code renders fonts (see this discussion e.g. on Linux systems [2]). We haven't found a good, general way of setting defaults that work across the huge array of environments where people run Codespaces.

1. https://docs.github.com/en/codespaces/prebuilding-your-codespaces/about-github-codespaces-prebuilds
2. [Linux] VSCode does not follow system regulated font rendering settings microsoft/vscode#107968

I need to use a full path to activate the numpy-dev environment on codespaces (noticed this today, but may have to do with #23411?)

(base) @melissawm ➜ /workspaces/numpy (f2pyFuncFix_23598) $ conda info --envs
# conda environments:
#
                         /home/codespace/micromamba/envs/numpy-dev
base                  *  /opt/conda

(base) @melissawm ➜ /workspaces/numpy (f2pyFuncFix_23598) $ conda activate numpy-dev
Could not find conda environment: numpy-dev
You can list all discoverable environments with `conda info --envs`.
(base) @melissawm ➜ /workspaces/numpy (f2pyFuncFix_23598) $ conda activate /home/codespace/micromamba/envs/numpy-dev/
(numpy-dev) @melissawm ➜ /workspaces/numpy (f2pyFuncFix_23598) $ # OK