Seems unable to use Python 3.6

[jeandet]

I have a Python 3.6 virtualenv in my home directory, I can use it with PyCharm when installed locally but with flatpack version it reports:

/home/jeandet/P3Venv/bin/python: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

Looks like Python3.6 should be shipped with PyCharm image?

[TingPing]

It might be worth having an extension point for newer python versions that you can optionally install.

[agates]

I think it would make sense to include any actively supported version of CPython. So currently 3.5, 3.6, and 3.7. Support for 2.7 is debatable as that's obviously EOL in about six months.

[Red-Eyed]

I don't think that pycharm has to be shipped with python interpreter
To manage python version conda or pyenv is generally used.

[agates]

@Red-Eyed PyCharm itself doesn't. However, it needs access to python available at runtime, even if a user wants to create a virtualenv.

[Red-Eyed]

Didn't get it.

I guess the issue is that the virtual env was created (don't know in which way) with python version 3.6, and depends on libpython3.6.so that is placed in /usr/lib host

flatpak runtime was updated to python 3.7, but python from virtualenv is still watching for libraries in /usr/lib folder, but that folder now in sandbox and contains libpython3.7.so or different

So, how can flatpak solve this?
To solve your issue, you'd rather need to build python statically linked and don't touch flatpak, isn't it?

Or you just want to add all python version into flatpak extensions?
Thanks

[agates]

I'm not an expert on this, but it seems like extensions would be a great route. This would allow users to optionally add the python versions they need, correct? Including python runtimes like pypy?

[Red-Eyed]

But there is tools for this: conda and pyenv.
So you can switch to any python version you want. w/o system side deps.

That tools have big community and growing.
Python users know that, and PyCharm has support for conda.

You could add conda as flatpak extension, but conda is easily installed and is not a problem.
So it would more redundant than helpful (and flatpak team then should maintain it: update versions at least)

[Red-Eyed]

So the problem is that users of flatpak don't understand sandboxing.
They use system tools, and then they stop working at sandbox...

So, in general: there always will be issues like that: "it worked at my host system, but doesn't at flatpacked IDE. flatpak sucks, fix it guys."

[Red-Eyed]

What will save us from such issues is something like --classic flag like in snap: make available host system from sandbox.
But AFAIK: it's not possible due to flatpak concept.

[agates]

Just to be clear, no one here is saying flatpak sucks. We are trying to use the tool, PyCharm the way we are used to.

I will test pyenv and see if it works with the intended use cases in the PyCharm flatpak, and also see if it works with tools like tox, etc.

[Red-Eyed]

Sorry for that, I meant that users compare snap version with flatpak and says that flatpak version doesn't work but snap works.

Thanks for understanding my point.

[agates]

Unfortunately, pyenv doesn't seem to be fairing any better. Just trying to get the version from a pyenv interpreter results in this:

sh-5.0$ ~/.pyenv/versions/3.7.7/bin/python3.7 --version
/home/agates/.pyenv/versions/3.7.7/bin/python3.7: error while loading shared libraries: libcrypt.so.2: cannot open shared object file: No such file or directory

And I'm not sure what would happen when trying to use a tool like tox to test multiple versions at once.

[Red-Eyed]

How did u install it?
I mean, pyenv builds python, so you need to build it inside a container, so that it will depend on libraries from a container, not host libraries

[Red-Eyed]

Can you show output of ldd ~/.pyenv/versions/3.7.7/bin/python3.7 ?

[jpork]

I guess I've the same issue. Running PyCharm 2020.1 Flatpak with Fedora 32. The fedora system installed Python-3.8.2. The venv is than also a 3.8.2 but PyCharm ships with Python 3.7. That wontj work together.

I've no influence on either of these Python versions. What can I do except not using the flatpak version of Pycharm?

IntelliJ Idea for Java has the same issue. But for Java there are pre-built binaries available. I can simply put them to /opt/java/version-xyz and add them as sdk to IntelliJ.

[b1oki]

How correct add python2.7 in PyCharm from flatpak?
I think about option --filesystem=/usr/bin/python2.7

[FakeShemp]

@Red-Eyed
Can you please just stop posting recommendations on using snap instead of flatpak. I get notified every time and it's highly irrelevant to any conversation of the bug. If you have an actual solution to a bug feel free to post it instead.

If you want to use snap packages just do so. No one is forcing you to use flatpaks and I'm happy they work like you want them to. But it is not a solution to any of the bugs of the flatpak version.

[FakeShemp]

@b1oki Python 2.7 is already included in the flatpak. It's at /app/bin/python2.7.

[Red-Eyed]

@FakeShemp
I understand your point.

But I just saying, that sandboxing and IDE is not compatible things.
I don't think that this is a flatpak related bug: application could not access host filesystem because of sandbox - this is a flatpak feature that couldn't be disable by design (AFAIK).

I like flatpak and os-tree, but permanent sandboxing forces me and other people (who just wants to use app distribution) to not use flatpaked packages that requires full host access.

[FakeShemp]

@Red-Eyed
PyCharm already has host access, as do most IDEs. It's mounted under /var/run/host.

[Red-Eyed]

@FakeShemp
Thank you, will check it out

[b1oki]

Python 2.7 is already included in the flatpak. It's at /app/bin/python2.7.

It's mounted under /var/run/host.

Thank you, @FakeShemp!

Can you please just stop posting recommendations on using snap instead of flatpak.

But I just saying, that sandboxing and IDE is not compatible things.

It is JetBrains recommendation:

[FakeShemp]

Oh all night. I'll just stop updating this flatpak then since the solution to any bug in the flatpak version is instantly solved by not using the flatpak version. Jetbrains approves. Wow folks, we solved all bugs ever.

[baudm]

@FakeShemp thanks for the hint about /var/run/host. The proper way of fixing these errors, I think, is to add the host library path (e.g. /usr/lib64) to the library search path like so:

$ flatpak override --env=LD_LIBRARY_PATH=/var/run/host/usr/lib64 com.jetbrains.PyCharm-Professional

I'm using a virtualenv via pyenv and for me, this trick works like a charm (pun unintended haha); I'm no longer getting library-loading errors.

Can this be added by default to the PyCharm flatpaks? For simplicity, /var/run/host/usr/lib and /var/run/host/usr/lib64 can both be added to the search path by default. I think that should cover most cases.

[baudm]

I'm not familiar with how Flatpak sets up the dynamic linker (ld), but adding the app and platform/runtime lib dirs before the host lib dir might be a more robust approach:

$ flatpak override --env=LD_LIBRARY_PATH=/app/lib:/usr/lib:/var/run/host/usr/lib64 com.jetbrains.PyCharm-Community

Given that the lib paths can be architecture-dependent (e.g. lib64), depending on the distro's implementation, a universal approach might not be feasible. That said, this should probably be added to the README since there are at least 3 issues in the tracker in which the root cause is the same-- loading errors of host libraries.

[AtomicMegaNerd]

$ flatpak override --env=LD_LIBRARY_PATH=/app/lib:/usr/lib:/var/run/host/usr/lib64 com.jetbrains.PyCharm-Community

Sadly adding the directive to modify LD_LIBRARY_PATH just causes the PyCharm flatpak to crash:

Process 147030 (pycharm-desktop) of user 1000 dumped core.

Stack trace of thread 2:
#0  0x0000000000000000 n/a (n/a + 0x0)
#1  0x00007f86d410033a n/a (/usr/lib/x86_64-linux-gnu/ld-2.30.so + 0x433a)
#2  0x00007f86d4115c6b n/a (/usr/lib/x86_64-linux-gnu/ld-2.30.so + 0x19c6b)

I am running on Arch Linux though so maybe that is making a difference because it is so bleeding edge?

[AtomicMegaNerd]

More efforts on this today. I need to expose libffi.so.7 to allow my local pipenv (~/.local/bin/pipenv) to work with my Python 3.8 from pyenv (~/.pyenv/versions/3.8.5/bin/python). This is the error I get, which is similar to all the others:
[pipenv.exceptions.InstallError]: ImportError: libffi.so.7: cannot open shared object file: No such file or directory.

I get the same error if I try to use the pipenv executable that is included in the flatpak image, but try to use my Python 3.8.5. Pipenv does work if I allow it to use the Python 3.7 included in the flatpak image. So yesterday on Arch I added the directory to the flatpak and set LD_LIBRARY_PATH. Pycharm crashed. Today I tried Ubuntu 20.04 and once the flatpak had access to /var/run/host/usr/lib/x86_64-linux-gnu where libffi.so.7 resides it crashes.

• I used Flatseal to give access to the image: /usr/lib/x86_64-linux-gnu:ro
• I also used Flatseal to give access to my home directory.
• I set LD_LIBRARY_PATH=/app/lib:/usr/lib:/var/run/host/usr/lib/x86_64-linux-gnu

It seems fundamentally that exposing the system's /usr/lib/* directories to the flatpak might not be the best approach?

Being stuck on only using the included 3.7 is the problem for me. If this image included the latest stable versions of Python, 3.7, 3.8, and 3.9 when it ships I could use it, but I do not want to be stuck on 3.7. I think this could be made to work!