Handle interpreted main executables

[probonopd]

For example, the GNOME Drawing app, which is written in Python

[probonopd]

Other example, TruFont, which is also written in Python.

Currently this "almost" works but does not complete because the main executable is interpreted.

# Ideally run this inside the manylinux Docker container
# so that dependencies get bundled from that very container

# Download an AppImage of Python 3.8 built for manylinux
wget https://github.com/niess/python-appimage/releases/download/python3.8/python3.8.2-cp38-cp38-manylinux1_x86_64.AppImage

# Extract this AppImage
chmod +x python*-manylinux1_x86_64.AppImage
./python*-manylinux1_x86_64.AppImage --appimage-extract

# Install taguette into the extracted AppDir
./squashfs-root/AppRun -m pip install trufont

# Change AppRun so that it launches trufont
sed -i -e 's|/opt/python3.8/bin/python3.8|/usr/bin/trufont|g' ./squashfs-root/AppRun

# Test that it works
./squashfs-root/AppRun

# Edit the desktop file
mv squashfs-root/usr/share/applications/python3.8.2.desktop squashfs-root/usr/share/applications/trufont.desktop
sed -i -e 's|^Name=.*|Name=TruFont|g' squashfs-root/usr/share/applications/*.desktop
sed -i -e 's|^Exec=.*|Exec=trufont|g' squashfs-root/usr/share/applications/*.desktop
sed -i -e 's|^Icon=.*|Icon=trufont|g' squashfs-root/usr/share/applications/*.desktop
sed -i -e 's|^Comment=.*|Comment=The truest font editor|g' squashfs-root/usr/share/applications/*.desktop
sed -i -e 's|^Terminal=.*|Terminal=false|g' squashfs-root/usr/share/applications/*.desktop
sed -i -e 's|^Categories=.*|Categories=Graphics;VectorGraphics;|g' squashfs-root/usr/share/applications/*.desktop
rm squashfs-root/*.desktop
cp squashfs-root/usr/share/applications/*.desktop squashfs-root/

# Add icon
sudo apt-get -y install imagemagick
wget -c "http://trufont.github.io/img/app.png"
convert -resize 128x128 app.png squashfs-root/usr/share/icons/hicolor/128x128/apps/trufont.png
cp squashfs-root/usr/share/icons/hicolor/128x128/apps/trufont.png squashfs-root/

# Workaround for missing dependency in PyQt PyPi
sudo apt install libxkbcommon-x11-0

# Remove unneeded parts
find squashfs-root/opt/python3.8/lib/python3.8/site-packages/PyQt5/Qt/plugins/platforms/ -type f -not -name libqxcb.so -delete
rm -rf squashfs-root/opt/python3.8/lib/python3.8/site-packages/PyQt5/Qt/plugins/egldeviceintegrations
rm -rf squashfs-root/opt/python3.8/lib/python3.8/site-packages/PyQt5/Qt/plugins/{audio,gamepads,geometryloaders,geoservices,mediaservice,playlistformats,position,renderplugins,sceneparsers,sensorgestures,sensors,sqldrivers,texttospeech,wayland*,webview,xcbglintegrations}
rm -rf squashfs-root/opt/python3.8/lib/python3.8/site-packages/PyQt5/Qt/qml
rm squashfs-root/opt/python3.8/lib/python3.8/site-packages/PyQt5/Qt/lib/libQt5{Bluetooth,Concurrent,Designer,Help,Location,Multimedia,Network,Nfc,OpenGL,Positioning,Qml,Quick,RemoteObjects,Sensors,SerialPort,Sql,Test,WaylandClient,WebChannel,WebSockets,Xml}*

# Convert back into an AppImage
export VERSION=$(cat squashfs-root/opt/python3.8/lib/python3.8/site-packages/trufont-*.dist-info/METADATA | grep "^Version:.*" | cut -d " " -f 2)

wget -c https://github.com/$(wget -q https://github.com/probonopd/go-appimage/releases -O - | grep "appimagetool-.*-x86_64.AppImage" | head -n 1 | cut -d '"' -f 2)
chmod +x appimagetool-*.AppImage
./appimagetool-*-x86_64.AppImage deploy squashfs-root/usr/share/applications/trufont.desktop
./appimagetool-*-x86_64.AppImage squashfs-root/

# Test it
./TruFont-*-x86_64.AppImage 

Approach:

• Check whether the main executable starts with a shebang
• If it does, extract the path from the shebang
• Resolve symlinks of the extracted path
• Check its architecture

[probonopd]

Deploying Perl scripts is another use case

[srevinsaju]

for python, would pyappimage be a good candidate?

[probonopd]

Well, certainly. Since we often get complaints that there are "too many different tools to make AppImages", it would be nice to find a solution to make it possible to also have interpreted main executables handled in go-appimage.

[srevinsaju]

Yea, that's a good idea. A single interface written in go, to use other low level tools with zero configuration. Looks like a really cool idea!! It would be really nice, just like how snapcraft uses plugins for different languages.

[probonopd]

Yes. If you are talking about "plugins", that's fine with me as long all of those end up in the same compiled binary. So that the user doesn't have to think about which plugins they need, and where to download them from, etc., since that would defeat the idea of "one tool, all automagic".