search

flathub / com.jetbrains.IntelliJ-IDEA-Ultimate

https://flathub.org/apps/details/com.jetbrains.IntelliJ-IDEA-Ultimate
15 stars 8 forks source link

add the host's usr/bin to the path #25

Closed muelli closed 5 years ago

muelli commented 5 years ago

This should allow for re-using tools on the host from IntelliJ.

muelli commented 5 years ago

This is to address https://github.com/flathub/com.jetbrains.IntelliJ-IDEA-Ultimate/issues/24

flathubbot commented 5 years ago

Started test build 5082

flathubbot commented 5 years ago

Build 5082 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/4865/com.jetbrains.IntelliJ-IDEA-Ultimate.flatpakref
TingPing commented 5 years ago

No no no no no no no no no no...

That is awful and broken and terrible and the worst idea ever.

TingPing commented 5 years ago

I realize its a bit blunt to just close this but this is impossible to work properly.

Binaries load data files for example and guess what they exist at a different path.

Binaries load libraries of course and they may exist but be a completely different ABI which is incompatible.

These are not problems you easily solve, you do not pull in different environments into the sandbox and expect them to run.

You have to package the tools you need.

x80486 commented 5 years ago

I would recommend to install Node.js via asdf or another package manager that puts/installs everything in your home directory. So far, I haven't had any issue(s) with those and this Flatpak – as long as everything needed is in the HOME directory; another option is to install Node.js via the Sdk Extension (recently added).

TingPing commented 5 years ago

Things installed into $HOME are only slightly better (paths are valid), but the binary is still entirely an unknown ABI and cannot be relied upon.

Create an extension point for tools you need.

muelli commented 5 years ago

Right. I know that this is controversial, at best.

Though, this is an IDE. You could argue that it is expected to run stuff from the host. Ideally, it would make use of the relevant DBus APIs, but I don't think we can maintain, let alone write, a patch that does that. We might ask upstream to detect being flatpaked and then perform the call on the host rather than in the sandbox.

With the status quo we can never call host binaries. With this proposal, we can do it sometimes. Probably most of the times, even. This is arguably better than not being able to do it at all.

Extensions sound great, but they seem to be much more work, especially for those often changing Web tools.

TingPing commented 5 years ago

I'm sorry but no this is a hard blocker for me.

This does not remotely work in any sane way and pretending it does for users gives the complete wrong expectation about what flatpak is or how it works.

I know it sucks to use but this is not a solution.