could you guys add toolbox to the flatpak for the ultimate sandboxed dev epereince?

[pyrotek45]

Instead of having the warning on the flatpak version of the terminal not working ( not being connected to the host terminal), why not just install toolbox inside of the flatpak with vscode, so you can use the flatpak version of vscode completely sand-boxed like it was supposed to be, while still having access to a toolbox so you can create your own dev environments totally separate for your host machine, this seems like a no brainer imho.

[gameatronist]

In my machine it is saying you are running an unofficial version of flatpak, and this was the message it gave me "This version is running inside a container and is therefore not able to access SDKs on your host system! " Do I have to run this command everytime? to run inside the sandox?

"flatpak-spawn --host "

[pyrotek45]

Right, my suggestion is to include the toolbox utility (that allows you to have a dev environment self contained, its like podman) so vscode wouldn't need to use the host machine to do devement.

[superuser-miguel]

@pyrotek45 You mean create a toolbox container with your development tools + VSCode in it?

[kon14]

@pyrotek45 You mean create a toolbox container with your development tools + VSCode in it?

No. This is about including toolbox inside the VS Code Flatpak instead.

That way you would be able to create podman containers to be used as remote dev environments for your projects and use a toolbox shell in your terminal without the need for flatpak-spawning with host access.

Ofc you'd still need podman for that.

[pyrotek45]

@pyrotek45 You mean create a toolbox container with your development tools + VSCode in it?

No. This is about including toolbox inside the VS Code Flatpak instead.

That way you would be able to create podman containers to be used as remote dev environments for your projects and use a toolbox shell in your terminal without the need for flatpak-spawning with host access.

Ofc you'd still need podman for that.

I'm not sure if it's possible, however it would be nice if vscode inside flatpak could be tied to the toolbox containers on the host machine at least, in a way that gnome builder does.

With gnome builder, you can select a toolbox environment as the dev environment in the settings. Having something like this should be possible if gnome builder can do it. Perhaps this would need to be a vscode extension maybe, I'm not sure how gnome builder does it tbh.

[pyrotek45]

But if the vscode flatpak could contain something like toolbox inside the flatpak itself, this would be ideal for anyone who would like to use immutable distributions, or would rather not have dev programs littered on their computers or host machine.

Not sure how it would be done but I think it's something everyone should work towards since many things are moving towards containers for development.

[kon14]

@pyrotek45 There's nothing stopping you from doing that already. Toolbox uses podman internally and VS Code's official MS remote container extension works just fine with it.

Simply select your podman container to be used as your remote container, then update your integrated terminal's launch command to spin up a shell inside that toolbox. I'm on mobire rn, but iirc that would be:

flatpak-spawn --host toolbox enter your-toolbox-name

[superuser-miguel]

@pyrotek45 You mean create a toolbox container with your development tools + VSCode in it?

No. This is about including toolbox inside the VS Code Flatpak instead.

That way you would be able to create podman containers to be used as remote dev environments for your projects and use a toolbox shell in your terminal without the need for flatpak-spawning with host access.

I understand what you are saying but, since you want to use a toolbox/podman container, it would be more convenient to just install VSCode inside your toolbox (can run GUI apps , I run sublime text 4 like this) along with all your dev tool (rust/python/go etc. ) I'm just mentioning this as a different workflow considering the difficulty with having the flatpak remote connect to a container with tools you need . . .

[pyrotek45]

@pyrotek45 There's nothing stopping you from doing that already. Toolbox uses podman internally and VS Code's official MS remote container extension works just fine with it.

Simply select your podman container to be used as your remote container, then update your integrated terminal's launch command to spin up a shell inside that toolbox. I'm on mobire rn, but iirc that would be:

flatpak-spawn --host toolbox enter your-toolbox-name

Didnt know that, however it still requires the host machine to have toolbox (my whole point was for the host machine to not be needed at all besides running the vscode flatpak). But I'm on mobile too atm. I'll have to give that a shot. Wouldnt there be anything special I would have to do inside the toolbox container for it to be visable to vscode though? Or would it be automatic?

[superuser-miguel]

But if the vscode flatpak could contain something like toolbox inside the flatpak itself, this would be ideal for anyone who would like to use immutable distributions, or would rather not have dev programs littered on their computers or host machine.

Not sure how it would be done but I think it's something everyone should work towards since many things are moving towards containers for development.

This is why i mentioned creating a toolbox with everything in it as an alternative to having a flatpak connect to a container with workarounds. This works well on Silverblue35 since your toolbox container can run GUI's/IDE's. All your tool in the container with it.

[pyrotek45]

@pyrotek45 You mean create a toolbox container with your development tools + VSCode in it?

No. This is about including toolbox inside the VS Code Flatpak instead.

That way you would be able to create podman containers to be used as remote dev environments for your projects and use a toolbox shell in your terminal without the need for flatpak-spawning with host access.

I understand what you are saying but, since you want to use a toolbox/podman container, it would be more convenient to just install VSCode inside your toolbox (can run GUI apps , I run sublime text 4 like this) along with all your dev tool (rust/python/go etc. ) I'm just mentioning this as a different workflow considering the difficulty with having the flatpak remote connect to a container with tools you need . . .

Yes I've tried this, a few problems though are things like fonts and rendering. Perhaps there is an easy fix I'm not aware of?

[superuser-miguel]

Yes I've tried this, a few problems though are things like fonts and rendering. Perhaps there is an easy fix I'm not aware of?

That's unfortunate, I run Fedora Silverblue 35 with a Debian Sid, Ubuntu 20.04, Arch-Latest containers, all have latest python tools, rust, go tools and a IDE (vscode + sublime text 4) with no problems. Just be sure to update the container immediately (with apt-get or pacman) after toolbox enter

[kon14]

@superuser-miguel No offense to you, I know this is technically a sort of solution to this problem, but to me personally it feels like an extremely hacky and inadequate one, at least for the likes of VS Code and any other app that has an internal undestanding of containers and can be configured to work with them. There's a few reasons why I believe that's the case. Off the top of my head, I can come up with these:

First things first, installing your editor inside a toolbox means you're now responsible for installing and updating the editor itself as well as all of its dependencies. Depending on your base image of choice that may or may not be a trivial thing to do.

More importantly, you're going to have to fs sandbox it yourself. It's not a big deal if you're going to allow spawning outside the sandbox, but why do it anyway.

Other than that, you now need to manually generate your own .application file launching VS Code from inside the toolbox.

[kon14]

@pyrotek45 I think I know what you're talking about. Have you tried selecting a terminal font? Adding the following to my settings fixed my zsh powerlevel glyph issues in the integrated terminal: "terminal.integrated.fontFamily": "Hack Nerd Font"

I forgot to mention you should also set podman as your docker executable in the remote containers extension.

[superuser-miguel]

@superuser-miguel No offense to you, I know this is technically a sort of solution to this problem, but to me personally it feels like an extremely hacky and inadequate one, at least for the likes of VS Code and any other app that has an internal undestanding of containers and can be configured to work with them. There's a few reasons why I believe that's the case. Off the top of my head, I can come up with these:

First things first, installing your editor inside a toolbox means you're now responsible for installing and updating the editor itself as well as all of its dependencies. Depending on your base image of choice that may or may not be a trivial thing to do.

More importantly, you're going to have to fs sandbox it yourself. It's not a big deal if you're going to allow spawning outside the sandbox, but why do it anyway.

Other than that, you now need to manually generate your own .application file launching VS Code from inside the toolbox.

No offense taken ! I'm simply offering an alternative to a problem I was having with IDE's and my dev tools with flatpaks. Sublime and VS Code both have the same issue with not being able to access certain tool outside of the flatpak. Time is money for me, and the ability to have a rootless container with all the tools and IDE inside the container was just enough to get me through.

Updating the packages was just dnf or apt-get so no problem there either.

You can launch VSCode from the toolbox by simply typing code & no problems there either.

Just offering an alternative that's worked for me...

[pyrotek45]

Honestly the real problem we have is, where do we put all of our dev tools when we have immutable distros.

We can flatpak most programs like vscode and the likes, but now they're isolated from the tools needed to compile and run, lint and debug our programs.

The best solution imho is if these toolchains could be flatpaks themselves, and used the way a host might use them. They should be available to vscode terminal out of the box.

This brings a new problem, even if we could add all these toolchains into the vscode flatpak, it would become bloated and more than likely contain software some devs dont need. So we need an easy way to include what toolchains we want.

In linux audio, there are many pluggins that are flatpaked and can be installed with flatpak and the flatpaked audio program can then access them once installed.

Is this not possible atm? if not I think this would be the best solution.

[kon14]

@pyrotek45 VS Code doesn't have to bundle said tools. All you have to do is build them as an extension and provide an extension mount point for them inside the Flatpak's definition.

As an end user trying to configure your own environment you don't technically need this either for anything that makes use of the freedesktop.Sdk as its runtime. All you have to do is find or build a freedesktop.Sdk extension for your tools and install it locally. Your apps are going to pick up its contents under /lib/sdk/your-appid-suffix.

Here's one way to go about it if you're going to do this on your own: Write a basic Flatpak manifest file in json/yaml format (eg: org.freedesktop.Sdk.Extension.protoc.yaml) that builds your software and moves it anywhere inside /usr/lib/sdk/your-appid-suffix (not /lib/sdk/, your buildtime directory structure differs to the one you'll eventually have mounted later on). If you're not going to share this with anyone you could even unpack a prebuilt binary for your system/architecture.

In my case, I needed /usr/lib/sdk/protoc/bin/ and /usr/lib/sdk/protoc/include/, so I created them and placed my files in there.

You can now build and install your local Flatpak build: flatpak-builder some-build-dir org.freedesktop.Sdk.Extension.protoc.yaml flatpak-builder --user --install some-build-dir org.freedesktop.Sdk.Extension.protoc.yaml

You may verify the files are indeed there like so: flatpak run --command=sh com.visualstudio.code ls /lib/sdk/protoc

PS: Ideally, most of these should be provided for end users. I'm simply pointing out how to fix this on your own in case anyone else stumbles into this trying to figure out how to make this work. Here's also a nice Flatpak building tutorial for you.

[lbssousa]

There's a third-party project by @owtaylor that makes it easier the integration of Toolbox containers with VSCode Flatpak: https://github.com/owtaylor/toolbox-vscode

It doesn't actually run toolbox binary, but it's able to spawn a Toolbox shell the exact same way a command like toolbox run does. On the other hand, it includes a wrapper script to spawn host system's Podman from VSCode Remote Containers extension.

Maybe he can bring some light to this issue.

[owtaylor]

Toolbox is just an opinionated wrapper for podman. I'm 99% sure that it's not possible to run podman inside the Flatpak sandbox. There won't be the necessary permissions. "Nested sandboxing" for Flatpaks - e.g. for browsers - is typically done by having Flatpak on the host create the nested sandbox. You could do something funky like run bundle the podman binary but run it with flatpak-spawn --host, but I can't see that as a good idea considering the complexity of podman stack. What the user probably wants, in any case, is integration with toolboxes on the host.

In practice, remote-containers + my toolbox-vscode script works quite well. (The heavy lifting is done by remote-containers, and the hard parts of the setup were mostly figured out by @lbssousa - my script just tries to glue everything together in a user-friendly fashion.) To fix the remaining gaps requires support from Microsoft since remote-* extensions are closed source.

I don't really see much that could be improved from the side of the Flatpak. The only thing I could think of would be to put up a dialog on startup (using zenity or whatever) offering to install a cli shortcut in ~/.local/bin/code. And that could my script slightly modified to just do 'flatpak run ...' in the non-toolbox case. (There's a PR to do that already). But that raises various questions like "how do you update the wrapper script".

[stanfieldr]

It would be cool if there was someway to grant access to the flatpak like a portal to a certain toolbox. Then VSCode could simply check if it was running in a flatpak and check which environments it had access to which might happen to be a toolbox

[alexojegu]

If podman-desktop exists as a Flatpak application, isn't it possible to use a similar approach for VSCode?

https://github.com/containers/podman-desktop/blob/main/.electron-builder.config.js

[kureta]

The method described at the end of this write-up seems to solve all my problems with toolbox/podman/vscode-flatpak.