devpod fails to parse `dependsOn`

[blooop]

What happened?

I want to use dependsOn and found there was an issue in devpod loft-sh#1950. I installed devpod version v0.8.11 as suggested.

I got this error:

devpod up . --recreate
15:41:56 info up.go:536 creating devcontainer
15:41:58 error root.go:101 Try using the --debug flag to see a more verbose output
15:41:58 fatal root.go:106 run agent command failed devcontainer up build image get extended build info fetch features process feature ./claude-code parse feature json: cannot unmarshal array into Go struct field FeatureConfig.dependsOn of type map[string]interface {}\n

What did you expect to happen instead?
devpod to rebuild environment. devpod version v0.6.15 is able to open this project but ignores dependsOn.

How can we reproduce the bug? (as minimally and precisely as possible)

devpod up github.com/blooop/python_template --recreate

Local Environment:

• DevPod Version: v0.8.11
• Operating System: linux
• ARCH of the OS: AMD64

DevPod Provider:

• Cloud Provider: N/A
• Kubernetes Provider: N/A
• Local/remote provider: docker
• Custom provider: provide imported provider.yaml config file: N?A

Anything else we need to know?
I was experimenting with pixi/conda and installed devpod 0.8.11 via pixi global.

pixi global install devpod --channel https://prefix.dev/blooop

[skevetter]

I notice your devcontainer uses the array format for DependsOn

https://github.com/blooop/python_template/blob/2646125cfeb8385a9c64312269141a417fe0f088/.devcontainer/claude-code/devcontainer-feature.json#L19-L21

Currently, DevPod only supports the object format outlined in the devcontainer specification

Property	Type	Description
dependsOn	object	An object (**) of Feature dependencies that must be satisfied before this Feature is installed. Elements follow the same semantics of the features object in devcontainer.json. See Installation Order for further information.

{
    "name": "My Feature",
    "id": "myFeature", 
    "version": "1.0.0",
    "dependsOn": {
        "foo:1": {
            "flag": true
        },
        "bar:1.2.3": {},
        "baz@sha256:a4cdc44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855": {}
    }
}

I will try to provide a better error message when this error is surfaced. Will you try switching to an object format and let me know if you have the same issue?

[blooop]

Thanks. That was not quite enough to fix it as I got:

devpod up . --recreate
16:53:12 info up.go:536 creating devcontainer
16:53:14 error root.go:101 Try using the --debug flag to see a more verbose output
16:53:14 fatal root.go:106 run agent command failed devcontainer up build image get extended build info fetch features compute feature order cyclic dependency found:\nghcr.io/devcontainers/features/node\n./claude-code\nghcr.io/devcontainers/features/node\n

From the spec its not clear to me if this should be considered an error. As far as I can tell its not an actual cyclic dependency.

However, if I removed the installsAfter: node then it works properly as shown here: blooop/python_template#114

[skevetter]

I think that might be correct to call it a cyclic dependency. I'll have to review the specification in more detail to determine what is expected. This sounds like a gray area between hard/soft-dependency links.

Is there a strong reason for using the same feature in dependsOn and installsAfter?

"dependsOn": [
        "ghcr.io/devcontainers/features/node"
    ],
    "installsAfter": [
        "ghcr.io/devcontainers/features/node"
    ],

[blooop]

I tested this by launching the devcontainer in VS Code, and it successfully handles both entries without throwing circular dependency errors. This matches what I’d expect:

• dependsOn is a hard requirement that ensures Node is installed.
• installsAfter doesn’t require Node—it just says “if Node is already being installed, run this after.”

So if a feature is already listed in dependsOn, having it in installsAfter as well basically becomes a no-op. It doesn’t break anything, but it also isn’t really needed.

The only real reason to include both is as a temporary workaround for DevPod v0.6.15, where dependsOn isn’t working as expected. In that case, putting Node in your main feature list and keeping installsAfter helps avoid the issue. Otherwise, it’s safe to just rely on dependsOn.

I will be using your version and have removed installsAfter so this won't affect my workflow, but as is I don't think it matches the devcontainer spec.

Thanks for working on these fixes to devpod! :)

[skevetter]

I tested this by launching the devcontainer in VS Code, and it successfully handles both entries without throwing circular dependency errors...as is I don't think it matches the devcontainer spec.

Thanks for validating how VS Code handles it. Devpod should have parity with what you can expect when working with VSCode devcontainers, so I'll note this as an inconsistency on DevPod's behalf that needs to be addressed.

If you could track down the devcontainer spec clarifying this, that would be much appreciated.

[blooop]

I did some more searching on the devcontainer spec but didn't find anything that useful or concrete. I can look a bit more, but would it be helpful if I found the devcontainer cli implementation of this?

[skevetter]

I will look at the devcontainer-cli implementation for comparison when I have the chance.