flathub / io.atom.Atom

https://flathub.org/apps/details/io.atom.Atom
6 stars 7 forks source link

linter-php not working #68

Open gtat314 opened 4 years ago

gtat314 commented 4 years ago

When installing a package named 'linter-php' I get console error mentioning:

[Linter] Error running PHP Error: Failed to spawn command php. Make sure php is installed and on your PATH

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?

cpba commented 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.

gtat314 commented 4 years ago

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.

cpba commented 4 years ago

[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).

takluyver commented 3 years ago

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:

cpba commented 3 years ago

@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.

SaladinAyyub commented 2 years ago

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.

  1. Using flatpak SDKs search them using flatpak search for example flatpak search php or let us say flatpak search rust
  2. Install the latest SDK provided by org.freedesktop
  3. using flatpak install org.freedesktop.Sdk.Extension.rust-stable
  4. Now launch the app giving it access to the SDK the easiest GUI app to do this is flatseal which is on flathub simply set the environmental variable in flatseal atom -> 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.