Repository navigation
How to use #16
Description
Activity
Good idea, though I'm not sure when I'll find the time to do so. It's not exactly meant to be used in a flatpak, but it should actually work.
What is your use case? The installation process is literally download the binary and pass it the name of the commands you want to run, from inside your container (be it Flatpak, distrobox or toolbox). Example:
./host-spawn lsAlso yes, the official way of installing this is compiling from source or downloading the pre-compiled binaries off Github. I will not maintain any package or provide it in any other way, but feel free to package it for your distribution if you want.
@1player Thank you for replying. Specifically, I ran into
host-spawndue to the bug that VSCode Flatpak has with running integrated terminals. (flathub/com.visualstudio.code#315)Now, the problem I have is how to pull this into the Flatpak. I tried a few things of just putting the binary in, but it doesn't seem to work. I assume something official would be something like a Flatpak-Builder recipe that can just be built and later added to your runtime/app (through Flatpak-Builder's local install function)?
Otherwise, I assume that you'd need to have it in a location that the Flatpak can read from.
Or maybe it would be best to just add it directly to the Flatpak?
If I understand correctly, you want to run
host-spawnfrom inside the VSCode flatpak. While it would work, flatpaks aren't made to be modified, so it's not this project's job to figure out how to do that. If you want to modify a flatpak, you need to recompile it yourself, and you'd have to include the host-spawn binary to have it available when you start VSCode.That said, a very hacky way would be for you to drop the
host-spawnsomewhere in.var/app/com.microsoft.Code(I don't have it installed so I don't know the correct path), and it would be available inside the flatpak. Since it's a static binary, doesn't require any dependency.A cleaner way would be to create a VSCode extension that downloads and installs host-spawn inside the flatpak.
In any case, my recommendation is never to run a programmer's editor from flatpak because of these exact issues. Such software often require a lot of external programs, and you'll face the same pain trying to make them available inside the flatpak. For comparison, on my Silverblue workstation, I run an Arch Linux distrobox container with code and emacs. Since it's a full distro, I can do whatever I want and add any program my editors require.
Some things work great in a flatpak. Editors ain't one of them.
Reacted by The LobsterSorry if it's not appropriate to ask here, but it does kinda go with a "how to use" question.
From the previous comment(be it Flatpak, distrobox or toolbox)
Since distrobox and toolbox use podman under-the-hood (afaik), is it possible to use this with a raw podman or docker container? At work we're building a custom podman container for stuff and we've been looking at ways to execute some host commandsI've tried it out in a completely custom podman container and it would just try to execute the commands within the container, so I'm not sure what is necessary inside the container for this to work. Thank you!
I should probably add the Discussion feature on this repo for these questions...
But no, you can't really use this on a raw container. The point of containers is to isolate them from the rest of the system.
On Flatpak, distrobox, toolbox & co. host-spawn works because their containers are mounted with access to the system DBus, and flatpak provides a Dbus service (technically marked as Development, so shouldn't really be used for real apps..) that is able to spawn processes on the host, which host-spawn then uses to do its thing.
If you give your raw containers access to the system bus, make sure that flatpak and its service are running, you can use host-spawn, but I would strongly recommend against using this setup for production applications, as it's a gaping security hole.
I figured that was the case, this specific container is one that does need some access to the host anyway. We're only containerizing to handle our dependencies, not for any security reasons. Unfortunately its a daemon application that isn't suited for flatpak, hence why we went with podman.
I will look into the distrobox/toolbox source a bit and figure out what's needed from my containers to make this work (adding /dev,/sys, and / as /run/host as volumes wasn't enough) or maybe I will also look into just using a named pipe as that may be simpler. Thanks again!
- Repository owner locked and limited conversation to collaborators
on Jun 3, 2023
It would be much appreciated if you could clarify how to use this. Beyond pulling it manually (which doesn't seem very stable or official) it would be nice if you could clarify the different ways of sourcing and installing it in a Flatpak.