Developing applications using Flatpak-packaged editors/IDEs

Project Discussion
22

I ended up writing that script. Here it is if you want to check it out: https://github.com/leggettc18/sb-project-setup

2 Likes
23

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!

24

Voted!
This will really make vscode great for silverblue, right now I am launching the IDEs from within the toolbox but this is so much better.

Gnome-Builder already does this pretty well, but when it comes to more exotic languages or frameworks(flutter, clojure, etc) vscode is my goto.

25

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:
flatpak --user override io.atom.Atom --env=PATH=/var/home/vrutkovs/go/wrappers-bin:/app/bin:/usr/bin:/var/home/vrutkovs/go/bin

Now whenever Atom’s go-plus invokes go or any of its binaries these are in fact running in CPU limited container.

I didn’t try this method for VSCode yet though

26

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.

27

I used to do the same, but I have many windows opened - and toolbox-based VSCode won’t merge them in a single app in Alt+Tab

I use a solution from Developing applications using Flatpak-packaged editors/IDEs - #19 by leggettc18

1 Like
28

I’ve managed to attach my Flatpak’ed VSCode to my Toolbox container via Remote-Containers extension. Instructions here: vscode extension? · Issue #610 · containers/toolbox · GitHub

Further discussion here: Support Toolbox (a.k.a. Fedora Toolbox) · Issue #3345 · microsoft/vscode-remote-release · GitHub

3 Likes
29

Thanks for all your work on this to make this work with Flatpak. You are making it easier to use Silverblue as a daily developer desktop.

30

Hello @lbssousa,
I would like to welcome you to the community discussion area. Thanks for coming bearing gifts of knowledge.

31

I think Flatpaks should include ~/.local/bin in path. The entrie home directory is shared with host, so with this simple change, user can install tools needed by IDEs in ~/.local/bin and it will just work in the IDEs packaged in Flatpak.

I can see it is already done in toolboxes, binaries installed in ~/.local/bin just works in all toolboxes because toolbox shares home directory, and includes ~/.local/bin in $PATH already.

1 Like
32

I sincerely hope people refrain from doing that.
Everyone can enable access to said directory through a simple override, why break the sandboxing default over this?

A graphical request based prompt for optional access to additional fs paths, upon the first execution of a newly installed Flatpak (or upon run with –permission-prompt), would be extremely useful users though.
The manifest file could include nested dictionaries of features paired with a description and all the filesystem/device/etc overrides required for it to be enabled.

33

I started a new related topic: Toolbox and Visual Studio Code Remote Containers - basically taking @lbssousa 's work with configuring Visual Studio Code Remote Containers extension and exposing it via a wrapper script that can be run from any toolbox.

2 Likes