Why bundling pyls

[exploide]

While this is not directly an issue in terms of a bug, in lack of a forum or other contact possibilities, I'll write here.

I noticed that the Atom flatpak ships with the python-language-server. Why is this the case? Since Atom is Electron/JavaScript based, I'm wondering why this is necessary.

[exploide]

As I use pyls by myself I just stumbled over some odd behavior, including recognizing configuration files. It turns out Atom only uses the version of pyls installed by this flatpak. This isn't something I consider useful. I would like to be in control what version of pyls Atom uses, and which plugins are installed (there is mypy?!).

While I'm new to the Flatpak world, I would assume intuitively that a flatpak only consists of the pieces necessary to run the software. But I'm curious why you decided to include this. :)

[TingPing]

Flatpak is sandboxed so you cannot use host libraries or anything. As such is it somewhat complicated to install new development tools. Atom is now making heavy use of language servers and I personally use Python so this was just a convenience. Once other language servers mature (like clangd) I was going to add them also.

[exploide]

Wow ok, that would really bloat the flatpak up. And there is no way to let the flatpak access the host system and call arbitrary tools?

Since the extension ecosystem of Atom makes heavy use of external tools, I consider this a drastic restriction and probably would not use it via Flatpak. :/

[TingPing]

The entire point of Flatpak is to be portable, so yes it by definition cannot interact with the host safely.

[exploide]

Ok, sad... Don't know why this affects portability since such calls were optional. But if you say this is how it is, I have to deal with it.

[exploide]

Just to let you know why I hoped it would be possible:

The sandboxing feature of Flatpak is really cool, especially when it is used to bundle proprietary software that would otherwise ship with an obscure install.sh or something like that. But in case of Atom, I would also install this piece of open source software with a deb or rpm file. The advantage of Flatpak, despite any sandboxing functionality, is that is offers a distribution independent way of installation (what about non deb/rpm distro users) and also includes its own updater (Atom's official packages don't). These are two good reasons for something like Flatpak, still without demanding obligatory sandboxing.

[TingPing]

Don't know why this affects portability since such calls were optional.

Say you wanted to use a Python library that links to say OpenSSL from the host. How do you do that from with in the sandbox? You don't, because its not portable, and pulls in host state that expects host paths, etc.

Anyway I can totally understand relying on the workflow for years and wanting to keep it.

[exploide]

It's not only that this is a habitual workflow. For a lot of software, the Flatpak approach will work fine, but I do not see how it fits the workflow of an extensible editor at all. Atom is used to develop, and there is a lot of different stuff that can be developed. What if I run a program and want to attach a debugger from within Atom? I read in the docs:

Access to other things, such as other processes, is deliberately not possible.

This matches your explanation. I can imagine a lot of common actions a developer would no longer be able to perform (e.g. just using a more recent compiler than the one included in the runtime). So for me, it seems that for a versatile editor, Flatpak is not the proper solution.

Still, thanks a lot for your answers!

[TingPing]

So, that technically is possible. You can run with --devel and it disables more of the sandbox. You can even run things indirectly on the host via that but it requires the application launch it in a specific way.

Also most extensions to Atom are via node.js which are portable and installed into the current directory. Only other language start to get complicated. Python can take advantage of virtualenv's for example.

[ghisvail]

I thought the ide-python package was supposed to provide pyls?

[exploide]

The ide-python package implements the language-server client to connect to pyls but it does not include the server implementation. Normally, you need to install it manually using pip. There is an open issue for ide-python requesting to automate the installation, similar to what e.g. ide-java does. But this is currently unresolved.

[ghisvail]

Correct. I guess you are referring to this issue.

[TingPing]

So there are a few other options I didn't mention.

• We could make an extension point so the user can install: io.atom.Atom.LanguageServer.Python or such.
• We can try to make flatpak run --command=pip3 io.atom.Atom install --user pyls work.

These are both not a great UX IMO.

[ghisvail]

It looks like the ide-python maintainer is open to the bundling of pyls, if that may help?

[TingPing]

If it works, great.

[TingPing]

This commit should be helpful btw: 761fe88

So if that addon can just run pip3 --user install foo everything will be in private directories and work.