Open gtat314 opened 4 years ago
Yes it runs in a sandbox, anything that requires an external dependency will fail to work.
However, this particular bundle sets --filesystem=host
which means that all your files are accessible from inside the sandbox. You may be able to use flatpak-spawn
to work around your issue.
You will find more details in issue #12 .
Note that for compatibility reasons the host's /usr
is mounted under /var/run/host/usr
when using --filesystem=host
, this is a detail that often trips people.
I am not really sure that I am following. Here what I did after I read your comment and #12 issue:
ls -l /var/run/host
ls: cannot access '/var/run/host': No such file or directory
just to be safe I added the --filesystem=host permission like this:
sudo flatpak override io.atom.Atom --filesystem=host
then:
flatpak run io.atom.Atom
then again:
ls -l /var/run/host
ls: cannot access '/var/run/host': No such file or directory
I also changed the target directory for the php executable at the settings page of the atom's extension 'linter-php' to "/var/run/host/usr/bin/php"
Now at the atom's console I get this message:
[Linter] Error running PHP Error: /var/run/host/usr/bin/php: error while loading shared libraries: libargon2.so.0: cannot open shared object file: No such file or directory
I also have no idea what should I be doing with the flatpak-spawn command.
[Linter] Error running PHP Error: /var/run/host/usr/bin/php: error while loading shared libraries: libargon2.so.0: cannot open shared object file: No such file or directory
This means you can't run your host's php binary inside the sandbox because it's missing dependencies, no matter, you can still use flatpak-spawn
to run it outside the sandbox.
I also have no idea what should I be doing with the flatpak-spawn command.
Sorry @gtat314 maybe I was a bit too cryptic, I will try to explain better:
flatpak-spawn
is a command that can be used from inside the sandbox to run binaries outside the sandbox.
You can do this conveniently by creating a shell script wrapper like this:
#!/bin/sh
flatpak-spawn --host php "$@"
Save it somewhere you want, with any name you want like for instance ~/flatpakphpwrapper
and make it executable chmod +x ~/flatpakphpwrapper
(provided you gave it the same name from the example).
Now go to linter-php's configuration in atom and change the PHP Executable Path to ~/flatpakphpwrapper
and it'll start working (of course, if you placed it somewhere in the sandbox's $PATH
and called it php
you won't need this step at all but that depends on your configuration).
Is it worth describing this situation in a Readme in this repo? Maybe even making some little Atom plugin to facilitate wrapping commands with a flatpak-spawn
script?
Unfortunately, this isn't really a corner case for Atom. There are a lot of plugins which work by running some external command (linters, language servers, etc.). The general pattern is that language-specific tooling tends to be written in that language, installed by that language's tools, and interfaced into the editor by running a subprocess. It's kind of a perfect storm for sandboxing - we want it to be able to talk to all sorts of things that can't easily be installed inside the sandbox. But at the same time, the complexity (and the rich ecosystem of plugins) means it's would be really nice to have it in a sandbox. :disappointed:
@takluyver I didn't do it then because it was a hacky workaround and I was hoping to find a better solution. At the time I was pursuing number of different ideas on how to fix this issue, but none were good enough and all of them required more time than I could invest.
In the mean time the flatpak ecosystem has mostly settled into using runtime extensions and flatpak-spawn
. Maybe it'd be good to do like com.visualstudio.code
does and open a text file explaining common workarounds on start, but I'm barely keeping up with version updates at this point.
Hi @cpba and everyone using flatpaks
In flatpaks to use language packages there are 2 ways the first one is the recommended and it is how flatpaks are meant to be used.
flatpak search
for example flatpak search php
or let us say flatpak search rust
flatpak install org.freedesktop.Sdk.Extension.rust-stable
FLATPAK_ENABLE_SDK_EXT=rust-stable
you can give it access to multiple SDKs separated by comas FLATPAK_ENABLE_SDK_EXT=rust-stable, php74
etc.. The Second way is using something that does not install stuff in root.. good examples would be rustup that installs everything in home directory. But this is not going to be for every language.
When installing a package named 'linter-php' I get console error mentioning:
I guess it has something to do with the sandboxed nature of flatpak, the inner works of which I am not accustomed with. From what I understand, my $PATH variable is not passing to the flatpak app, so I tried this:
flatpak run --env=PATH=$PATH io.atom.Atom
which returned:
bwrap: execvp atom: No such file or directory
Php is installed and running on my machine:
which php
/usr/bin/php
php -v
PHP 7.3.11 (cli) (built: Oct 22 2019 08:11:04) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.11, Copyright (c) 1999-2018, by Zend Technologies
Any ideas?