Pixi DevContainer

[brad-jones]

At my day job we have been using devcontainers for a while now but some of our larger projects the devcontainer config has become a bit hard to maintain.

So in my time off I put this together. https://github.com/brad-jones/pixi-devcontainer

My hope is that pixi will help us tame some of the crazy Dockerfiles we have & potentially even allow us to wean off the devcontainer concept altogether & get some performance back.

Anyway let me know what you think.

Probably the only thing I'd love some help with is this bit: features/src/pixi/install.sh#L51-L57
Surely there has to be a better way than the tmux dance I am doing?

[ruben-arts]

Hey @brad-jones, thanks for your work!

To avoid the tmux dance we would need to output the activation script of the environment right?

[brad-jones]

Yeah basically just need an extra flag for pixi shell so that it outputs the temp activation script to stdout instead of starting a new shell.

So we can do something like: . $(pixi shell --init --manifest-path /workspace/foo/pizi.toml)

[schlich]

This is great! I've been searching the feature index hoping for pixi to show up 🙂 I noticed that was a TODO on your repo's README, do you think it is ready for publication? I will give it a go!

[schlich]

Hmmm my project is getting stuck during the OnCreateCommand step. looking at your source code here i'm wondering if it's the last step that's causing trouble? I do have an existing pixi environment (wouldn't we want to keep this instead of removing it, for caching purposes? this is what i do with other virtual envs and dev containers). I'm not sure what the concern about symlinking that you list in the comments is all about, but i'm sure it's for good reason!

[brad-jones]

do you think it is ready for publication?

haha no probably not. I've built it for my team's needs but probably needs more feedback like this before I'd make it official. Most of my team isn't even back from holidays, have been waiting for them to really test it out for me. Also as good as Pixi is, if I'm honest I've found many discrepancies & annoying bugs in the pixi/rattler ecosystem, I'd hate to add more of them 😂

wouldn't we want to keep this instead of removing it, for caching purposes? this is what i do with other virtual envs and dev containers

My understanding is that a pixi environment is specific to the host in which it was installed. ie: a Windows environment would not work inside a Linux devcontainer right? Hence the docker volume to keep the devcontainer's environment isolated from the host systems.

At the very least pixi validates that the .pixi/prefix dir is the same. Hence the symlinking to make the pre built environment appear under the path pixi expected.

There is possibly a third pattern that could work when the host is also Linux. And that is to not volume mount ./.pixi but instead ensure that the devcontainers workspace mount is the same as the host.

eg:

{
  "workspaceFolder": "${localWorkspaceFolder}",
  "workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind"
}

But that would only work if pixi installs the same environment regardless of Linux distro?

Anyway I'm a pixi newbie so more than happy to make changes based on feedback like this. Perhaps submit a bug over at https://github.com/brad-jones/pixi-devcontainer/issues with a bit more detail & I'll endeavor to have a look at it over the weekend.

[schlich]

I guess in my workflow, I usually manually create the environment after i've already built and opened the dev container (although this could probably happen someway during the lifecycle commands), so thus i've never had to deal with mismatches -- but the advantage is that the next time i want to rebuild, the environment does not need to be recreated due to the source code volume mount, and pixi can use can use the .venv as-is. I'm a little new to the conda side of things but i'm assuming it'd work mostly the same way as my poetry/hatch environments have.

Does that help answer your questions? I may be missing something, i need to parse through your reply more fully when i can focus on this a bit more. I'll try to get to submitting a bug, busy weekend for me, but i'll definitely be coming back to this!

[pavelzw]

Binding the .pixi directory directly is not good since it won't work outside of the environment.

Adding

    "mounts": ["source=${localWorkspaceFolderBasename}-pixi,target=${containerWorkspaceFolder}/.pixi,type=volume"],
    "postCreateCommand": "sudo chown vscode .pixi && pixi install",

fixes this issue. See #997 (comment)