The first option is the one chosen by gnome-builder. gnome-builder tightly integrates with flatpak and doesn’t actually build things in the context of the gnome-builder sandbox and its runtime, instead if recursively creates other sandboxes for builds. This means that you get to pick any runtime for your builds which may be completely different than the one that runs gnome-builder itself. This is quite powerful, but requires a lot of intimate support for this model in the IDE.
There’s a variant of this - which is for the IDE to do builds in a container. If the end thing you are creating is a graphical application, then doing the builds as Flatpak builds makes a lot of sense. If the end thing you are creating a server app, then a container build is going to work better - and also allows using prepackaged Fedora dependencies. I don’t know of any examples of setting up a Flaptak’ed IDE to target container builds, but many IDE’s will have some sort of container support that can potentially be adapted for this purpose.
Right, that’s the case for me - I am using Silverblue primarily to develop server-side apps for Kubernetes (and base operating system components), not desktop apps. So the flatpak IDE story basically crosses all 3 systems (flatpak, dev/pet containers with podman, and local oc cluster up testing).
I’m a newbie at this but I had briefly looked at what Theia IDE is doing and I like some of their ideas Theia - Cloud and Desktop IDE Platform for composabilty
This tooling issue is real and I guess a lot of us need to readjust to this container mindset to be productive.
Maybe you could somehow redirect Python has a wrapper for flatpak-spawn --host python3 or similar? This is how GNOME Builder’s and Tilix’s terminal work.
From reading the extensions description, this seems like exactly what it’s meant for. Means extensions for Atom, VSCode, etc. can be created per language (Python, Go, PHP, Ruby, etc.) which can contain all the tools needed for full language/IDE support (library, linter, etc.). I’m assuming a Flatpak extensions is easily distributed on Flathub and conveniently displayed in the GNOME Software app as add-ons to the main application. That makes it user friendly to extend your favorite editor with support for the required languages so the Atom/VSCode in-application extensions work too. Even makes it easy to scope extensions for major language versions (Python 2/3, PHP 5/7, etc.).
Anything with a wrapper requiring users to alter the language commands inside their editor to flatpak-spawn, or building all kinds of podman containers, or using fedora-toolbox is simply not user friendly. If we wanted to tinker with everything, we would probably all be using Gentoo. I know the solution is upstream in Flatpak/Flathub, but i.m.h.o. Fedora needs that to be a “it just works” solution.
I just switched to running emacs from inside toolbox and I am way happier than I was with previously having it layered on the host, and trying to hook up e.g. M-x compile to run in my previous dev container. Also briefly tried GNOME Builder inside toolbox, seemed to work OK but I have too many years invested in Emacs at the moment.
This pattern of running GUI apps inside toolbox definitely has disadvantages too, e.g. GNOME Shell/Software doesn’t know about them, but on the flip side most editors and IDEs will Just Work this way to integrate with your build tools.
toolbox create and toolbox enter are pretty user friendly. Also being able to use dnf as you would in workstation is pretty user friendly. The toolbox container idea was meant for developers, and can be tweaked to suit then trashed and rebuilt from scratch a different way. But it isn’t exclusively for dev’s, and it does provide a very neat rootless container to play around with some ideas in. If I could spin up a container for my windows app’s I need for my business I’d be overwhelmed by joy for finally being able to ditch the last vestige of a horrid OS. Instead of having to run it in a VM, ughh.
What I’m currently doing with VS Code is taking advantage of workspaces and the shell-args config option to automatically enter the toolbox for a project when I open the terminal while I have the project’s workspace open. I don’t get to use the Rust extension with the RLS this way (at least I haven’t gotten it to work yet) but I can adjust to not having it by getting in the habit of running Cargo Check often. IMO the containers are worth the workflow adjustments.
So this is what my .code-workspace file looks like for one of my projects. This was generated automatically by VS Code. If you don’t want to use workspaces there’s also folder settings you can set in VS Code’s integrated settings editor. You can get to the settings editor with the gear in the bottom left corner. From there you switch to Workspace Settings and you’ll find the option under Features → Terminal → Integrated > Shell Args: Linux. The cool thing is that since these .code-workspace files are just json these could be created automatically with a script. I plan on writing a script that will automatically generate a container and a code-workspace automatically, and maybe also enter the container and install certain packages according to arguments given.
Thanks for sharing! I’d be interested in seeing how the script turns out. I haven’t really tried extending VScode that much. I suppose I should take another shot at it
Well the script I was thinking about writing either would be just a bash script or a small program, probably written in Rust. The code-workspace file is just a JSON file describing the path of the project and its workspace-specific settings, so you wouldn’t necessarily need VS Code to make it. As a matter of fact, that particular option just has you open the “settings.json” file (which is your workspace file if you are in workspace settings tab) and edit it manually anyway.
I’m assuming VScode’s remote development extensions only work with Docker containers? It would be great to be able to attach Flatpak VSCode to a running toolbox container.
edit: found a feature request for podman container support–needs more votes!
I use Atom and for golang development I did the following:
Created a new cgroup limited by CPU time:
/etc/cgconfig.conf
group groupname {
perm {
# who can manage limits
admin {
uid = 0;
gid = 0;
}
# who can add tasks to this group
task {
uid = 1000;
gid = 1000;
}
}
# create this group in cpu and memory controllers
cpu { }
memory { }
}
group groupname/foo {
cpu {
cpu.cfs_period_us = 1000000;
cpu.cfs_quota_ns = 500000;
}
}
Updated toolbox to pass --cgroup-parent sandbox to new toolbox container
Created a new dedicated toolbox container - go-1.12 and installed golang from F30 repos
Created a script to generate wrappers for golang binaries:
~/go/wrappers-bin/create-wrappers.sh
#!/bin/bash
container_name="go-1.12"
prefix="flatpak-spawn --host podman exec -u 1000 -i"
gobin="/home/vrutkovs/go/bin"
bins=$(find $gobin -executable -type f)
for file in ${bins[@]} go gofmt; do
echo -e "#!/bin/sh\n\n${prefix} ${container_name} $(basename $file) \$@" > ./$(basename $file)
done
chmod 0755 ./*
Generated wrappers for installed go binaries
Updated flatpaked Atom’s PATH to have a path for wrapper binaries first:
Interesting approach. Has some advantages and disadvantages. I now use VS code installed in my toolbox container, and I basically live in the toolbox, running various utilities there (e.g. git-annex, random aws CLI invocations etc.) Having the editor just aware of golang binaries but not others would be…confusing I think? In particular I do use the integrated terminal in VS Code a lot.