Notes on UV Path, Quick Start, Build Hiccups, and Wizard

[0xScratch]

Over the last few days, I've been messing around with these pre-built devcontainers. Thought I'd drop this issue to jot down some feedback and observations from my tests. Overall, they've been working pretty well, but I did run into a couple of quirks worth mentioning.

Outdated UV_LOCAL_BIN Path

While troubleshooting a weird uv not found error (more on that in the Intermittent Issues section below), I ended up checking the Astral docs, since that’s where we install uv from. There, I stumbled on this note in the Uninstallation section:

Prior to 0.5.0, uv was installed into ~/.cargo/bin. The binaries can be removed from there to uninstall. Upgrading from an older version will not automatically remove the binaries from ~/.cargo/bin.

Feeling intrigued, I dug deeper and found this section of the docs, which states that uv is now installed to ~/.local/bin by default. Additionally, it also mentions options to change this path if needed.

This caught my attention because our Dockerfiles still set ENV UV_LOCAL_BIN=$HOME/.cargo/bin in several places. It seems like this might need an update to match the current uv setup—maybe something to look into? (Though it doesn't seem to mess up the devcontainer build so far.)

Quick Start Didn't Quite Work For Me

In the README of this repository, there are Quick Start and Kick-off sections that intend to guide developers in setting up these containers. But, if I follow the mentioned steps, i.e.:

1. Choose variant - auditor (let's say)
2. Navigate to variant directory - cd .../.devcontainer/auditor
3. Open in VS Code, and Select Reopen in Container after pressing Ctrl + Shift + p

This is the result I got

Which is, unfortunately, not what I expected. I’m using the DevContainer extension by MS and don’t recall changing any settings, so I’m not sure why. However, there's a slightly different approach which do work:

1. Clone the repo, and cd into it.
2. Now press Ctrl + Shift + p and select Reopen in Container right away.

Here, it lets you select all the devcontainers that are present in the .devcontainer directory—a pretty smooth way to get going!

Intermittent Issues (Weird Build Hiccups I Noticed)

While interacting with the devcontainers, I hit some build problems that popped up now and then. For instance, one issue might pop up, and upon mitigating it, the build will run smoothly. However, if I try to revert that fix and build again (after clearing the cache), then sometimes the build still runs well, as if no issue was present in the first place.

I was feeling perplexed whether to include this section or not, as it doesn't prove of much use and doesn't even suggest any changes to Dockerfiles. However, I still decided to include this, as I personally don't assume these devcontainers will be built right away in one go for everyone out there. Moreover, if the temporary fixes suggested feel right, they could be added as comments. So, here's what I ran into:

uv not found error

I got this error when playing with the auditor variant, and it looks like this:

 => ERROR [dev_container_auto_added_stage_label  6/18] RUN uv python inst  0.3s
------
 > [dev_container_auto_added_stage_label  6/18] RUN uv python install 3.12:
0.267 /bin/sh: 1: uv: not found
------

On line 60 (in auditor's Dockerfile), we are installing uv using RUN curl -LsSf https://astral.sh/uv/install.sh | sh, and then it throws an error at line 71 - RUN uv python install 3.12, saying that uv isn't there at all. Trying to build it again didn't help either. A similar error was also witnessed in the minimal variant. To me, it felt like the Path issue, and hence changing line 60 to:

RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    export PATH="${PATH}:/home/vscode/.local/bin" && \
    uv python install 3.12

And commenting out RUN uv python install 3.12 fixed it that day.

Issue with long chain of installs

Within the legacy variant, lines 82-92 contain several tools that are being installed with a single RUN command. Sometimes, one of those downloads was failing due to a network hiccup or some other reason, which led to the failure of the whole chain, and Docker stopped the build. This was a bit annoying, even though my network was pretty stable. It's better to separate these tool installations (in 2-3 RUN commands) so that it runs smoothly, and if one of those RUN commands faces an issue, Docker cache can act as a saviour, and there won't be much resource wasted on installing all the tools again.

Along with that, there was a sweet hack suggested by GitHub Copilot in case a tool is really having some trouble during the installation while building the container, but runs well if you try installing it in your local environment. Let's say if that particular tool is napalm-toolbox (which was actually the one I faced the issue with), then the following could be helpful:

-RUN uv tool install napalm-toolbox
+RUN for i in 1 2 3; do uv tool install napalm-toolbox && break || sleep 5; done

Devcontainer Wizard

Honestly, this is a pretty good deal when it comes to either building a custom devcontainer or even using the pre-built ones. No major issue popped up while trying it out. It's just that there's a little tweak that can be made in one of its functionalities. As we know, after one reaches the point where it asks, "Select an interface to attach to the devcontainer", we have two options to select from: either Terminal or VS Code

Upon selecting Terminal, one can access the container right away—fair enough and expected. However, if one chooses VS Code, it opens the directory where the devcontainer lives, like it’s running code <path to directory> behind the scenes. That’s cool, but then I had to manually hit Ctrl + Shift + p and select "Reopen in Container" to actually get inside, which wasn’t quite what I had in mind regarding the VS Code option. I was hoping it might handle that extra step automatically to streamline the process and thus provide a better experience. I am not sure whether something like this can be implemented or not, as it has a bit to do with the devcontainers extension itself, but if it is possible, then maybe it's worth a shot.

[0xScratch]

Just noticed that Contract Explorer in auditor variant is throwing out some errors related to the missing slither-lsp.

Clicking on Go to Output shows this:

Moreover, if we check out the Requirements section, our solution is right there.

Thus, after making the following change in my auditor variant's Dockerfile (and building it again):

RUN uv tool install slither-analyzer && \
+   uv tool install slither-lsp && \   # Comes handy for contract-explorer extension
    uv tool install mythril && \
    uv tool install crytic-compile

I get these results...

And, if we look at some contract after opening a foundry project in VS Code, then it is indeed working

Though there's still a minor UI glitch with the extension:

I'm not sure why the UI isn't behaving as it should, but if I figure out a workaround, will drop it here!

[d4rm5]

First of all, thanks for your feedback! I's great to see people testing our dev container suite.

I'll fix the uv and slither-lsp issues in the next commit.

The legacy variant won't be updated; it's kept in the repository for existing users. For new dev container users, we recommend the other variants.

Regarding VS Code attaching in the Devcontainer Wizard: unfortunately, we haven't found a reliable command to consistently open a specific container. If you find one, please share it here, and I'll replace the open command.

[0xScratch]

Thanks for creating the PR!

Regarding the "reliable command", just landed on this issue where the devs discussed similar ideas. There were quite a few solutions suggested—both in commands and script form—out of which, this particular comment gained my attention, or I can say, felt a bit promising. Though it has some caveats...

So, the original command mentioned in the comment looks like this:

mypath="$(wslpath -w $PWD)" && p=$(printf "%s" "$mypath" | hexdump -v -e '/1 "%02x"') && code --folder-uri "vscode-remote://dev-container+${p}/workspaces/$(basename $PWD)"

But this will certainly fail when used right away, and thus, some tweaks are to be made:

• First off, it requires a specific directory layout for devcontainers. The main part of the command, i.e., code --folder-uri "vscode-remote://dev-container demands a particular format, similar to how pressing Ctrl + Shift + p and selecting Dev Containers: Reopen in Container needs one.

  Here's a tree structure comparing two devcontainers (legacy and minimal):

  .
  ├── .devcontainer
  │   └── legacy
  │       ├── Dockerfile
  │       ├── devcontainer.json
  │       └── motd
  └── minimal
      └── .devcontainer
          ├── Dockerfile
          └── devcontainer.json

  The legacy is structured in a default form, and works well with Dev Containers: Reopen in Container. But the command fails there because it looks for the .devcontainer/devcontainer.json pattern. That's why I had to switch to the minimal structure and run cd minimal before executing it.

• Another change that's needed is to be done here: ...${p}/workspaces/$(basename $PWD)", at the end. Here, we need to mention the directory we want to hop into after our devcontainer takes off. Otherwise, it will humbly ask us to select a workspace repeatedly. In our case, the whole command turns out to be:

  mypath="$(wslpath -w $PWD)" && p=$(printf "%s" "$mypath" | hexdump -v -e '/1 "%02x"') && code --folder-uri "vscode-remote://dev-container+${p}/workspace"

So yeah, with these changes, I managed to get a one-liner command to directly launch my devcontainers from the terminal. But still, it doesn't feel like a permanent solution yet. As we just witnessed the primary requirement, i.e. to adjust the directory layout, which will lead to issues in the Dev Containers: Reopen in Container method.

It felt more like a workaround on an individual basis, rather than something to be applied in devcontainer-wizard. Still, I will definitely recommend looking at some solutions mentioned in the issue, and if there's a way to adapt this command without messing with the layout. Moreover, I will try to find some ways on my end as well.

[d4rm5]

Thank you for your exploration of that command! We'll wait for an official implementation on VS Code to support that across all operating systems using the same approach.