flatpak: $PATH environment variable overriden

[sebastien]

I'm only using the Flatpak version, but I've noticed that the $PATH variable is reset, which is problematic as it's quite restrained:

PATH=/app/bin:/usr/bin

Is there a way for the flatpak to not reset the environment's PATH?

[daa84]

not sure, you can try --env option of flatpak run command (man flatpak-run) but if i understand right - flatpak uses sandbox so it does not allow to run commands from outside of container.

[alerque]

By design, nothing you run in your shell will be able to change that environment variable except the shell itself. Apps you run can only change environment variables for themselves or their child processes. I assume the flatpack (being a sandbox) sets up a working PATH variable for it's child processes. This probably is the only path that would be useful for child processes anyway.

In other words by design I'm pretty confident neither neovim-gtk nor any other flatpack is resetting your shell's PATH environment variable. On the other hand what the flatpack version is able to do internally and what access it has to the host system (e.g. to run the :terminal command and or :!<shell_cmd>s) I have no idea. Does it have any at all?

[sebastien]

@daa84 I've tried the --env flag (from bash):

$ flatpak run --env=PATH=$PATH org.daa.NeovimGtk/x86_64/master
bwrap: execvp nvim-gtk: No such file or directory

which is not that surprising as /app/bin is not in the path anymore (:!echo $PATH lists /app/bin:/usr/bin). The main problem is that the Flatpak version is then unable to access/use any utility that is not in /app/bin or /usr/bin.

Worse, :make or !make results in /bin/sh: make: command not found, even though make is indeed in /usr/bin.

The overall question is how can the Flatpak version of NvimGtk preserve the host environment so that host commands are available and runnable from vim. Without it, the Flatpak version becomes an island that is not able to interface with the system and its tools (compilers, linters, etc).

[alerque]

I don't have any experience with Flatpak in particular, but in general when dealing with a containerized environment the answer is yes: the container is an island. The Flatpak sandbox documentation states this explicitly. Interacting with other processes is probably not an option. One would need a flatpack bundle that included the compilers, linters, etc. as part of it's sandbox.

The next section on portals explains how Flatpack apps get access to read and write files on the system or talk to print services, but those are different that the kind of ubiquitous find and execute anything type of feature you are looking for.

I think your answer is going to be that you want to install nvim-gtk on your host system, not run it in some containerized app system.

P.S. I'm writing these Github comments in nvim-gtk using GhostText. Put that in your Flatpak pipe and smoke it ;-)

[daa84]

It is possible to run command outside of sandbox with special dbus api https://github.com/flatpak/flatpak/blob/e7f478c60148907b25a6fc3cac7355628f377a9e/data/org.freedesktop.Flatpak.xml#L42 So it possible to run nvim from outside of container. But to run nvim inside of container with possibility of running outside commands it is need to modify nvim to support this command

[daa84]

Hm, also i find flatpak-spawn, maybe this can help if use as a wrapper for make command

[alerque]

@daa84 and @sebastien I'm curious what distribution you guys are on or system situation in which using a flatpack installation offers some advantage over installing it on your system. In what scenario would you both want your editor to have access to your system and be sandboxed in a jail? What are you gaining by not just installing it on your system using the normal system package manager?

[daa84]

Container is not about isolation only, it is also allow to build single executable with all dependencies that can run on any system. All dependencies tested and known versions. Plus current way to not build nvim-gtk from source is flatpak only

[sebastien]

@alerque as @daa84 was saying, some distributions (like Fedora) don't have a native package, which means that unless you want to build nvim-gtk yourself, you could use the Flatpak version. In this case, it's more about having a distribution-independent package than an actual isolated, containerized environment (which is actually what we don't want in this case).

[alerque]

@sebastien In that case it seems to me the thing to do is get a native Fedora package build. I used to build packages for an RPM based distro, and now for Arch. It's not that complicated. I believe Fedora has Copr (or something like that) for user contributed package builds. It seems like that would take less time to setup than we've already spent discussing Flatpack. Sure it has to be done for every distro (like I said I've been packaging hundreds of apps for several distros over 20 years so I know it takes effort) but in the end you have distribution native packages that integrate perfectly into the system.

[sebastien]

@alerque Yes, that would be great. How can we get started? I don't know how to create RPM packages, but I'd be happy to help you if you have experience. Given that neovim-gtk is pretty much the best GUI for neovim, it would make sense to have it since neovim is already part of the Fedora packages.

[alerque]

@sebastien I started to look into what you would need to do, and it looks like there already is a COPR repository for neovim-gtk. The maintainer for it (@tsahyt) seems to have automatic rebuilds turned off so you might need to poke him periodically to got new builds, but it looks like it should be working to me. I don't have a Fedora system handy to test on, but to the best of my knowledge it looks like this has already been taken care of properly for Fedora. Also if you want to just build it yourself using rpm you could use his spec file to do so. You just need a spec file and the RPB build tools package for the builder that goes and fetches the sources, builds them, and makes an RPM based on the spec.