niess / python-appimage

AppImage distributions of Python
https://python-appimage.readthedocs.io/en/latest/
GNU General Public License v3.0
175 stars 24 forks source link

Trying to use ranger with python-appimage #68

Open qlibp opened 1 year ago

qlibp commented 1 year ago

Thank you for reporting this issue.

I don't see your libtinfo warning when running the Python AppImage. Would you know what command triggers this?

Nevertheless, I also have issues with manylinux_2_28. In my case (Debian 10+) the command line does not work properly. E.g. I cannot erase/correct when typing a Python command. In addition, the curses package does not work properly (initscr fails with a no TERM error). However, when running directly from the Docker image it does work.

A difference between manylinux_2_28 and others is that it uses libtinfo.so.6, instead of libtinfo.so.5 for others.

Originally posted by @niess in https://github.com/niess/python-appimage/issues/57#issuecomment-1314979246

If there any plan to fix this problem? I could not use python-appimage's release binary with ranger file manger.

niess commented 12 months ago

Hello @qlibp ,

not that I am aware of, unfortunately. I personally, do not use these versions of manylinux, and since time is running short, I am focusing on what I personally need :P

Just in order to understand your problem, why is manylinux_2_28 needed in your case?

You could also try this manual patch:

If you don't use curses, as a temporary patch, you could try to delete libtinfo.so.6 from the AppImage. In my case, it solved the command line issues. Indeed, my local system actually uses libtinfo.so.5.
qlibp commented 12 months ago

I just need a linux version as my working env is on ubuntu. Python's battery-included lib curse rely on such system lib, if we delete libtinfo.so.6, can we still import that lib?

Or maybe you could show me a python3 version that could import that lib correctly?

niess commented 12 months ago

The issue seems to be that the host already has libtinfo, but a different version than the one packaged in the AppImage (e.g. 5, instead of 6). By deleting the one packaged in the AppImage, the host one should be used by Python (which seems to work as well, in this case).

But, if you have no specific reason to use manylinux_2_28, then I would rather use manylinux2014. For example, this image, assuming it matches your system.

qlibp commented 12 months ago

Oh Thx! I would have a try then.

Would you like to elaborate a little bit more on what's the general difference between manylinux_2_28 & manylinux2014?

niess commented 12 months ago

You can find a summary of manylinuses tags over there. A key difference is the version of GLIBC that is used. This (mostly) sets compatibility. For example, manylinux_2_28 requires GLIBC 2.28+.

But there are also other possible compatibility issues, e.g. the one you experiment with libtinfo being newer than your system one.

Thus, if your intent is to distribute a Python-based application, I would rather use an older image, if possible. This would provide larger compatibility.

qlibp commented 11 months ago

Still, problem with curses module when using ranger. With the appimage, It said that _curses.error: setupterm: could not find terminal, but it works fine with system's python3. Don't know why it can't get the needed information.

And I'm using CP310-manylinux_2014_x86_64 appimage on ubuntu 20.04

joedefen commented 5 months ago

FYI, I see the same issue with python3.12.3-cp312-cp312-manylinux2014_x86_64.AppImage; reproduce with

python3
import curses
curses.initscr()

This is a show stopper for me unfortunately. Is this a limitation of them all. Saw nothing in the docs.