pyfa-org / Pyfa

Python fitting assistant, cross-platform fitting tool for EVE Online
GNU General Public License v3.0
1.6k stars 406 forks source link

Release AppImage package #2410

Closed ghost closed 2 years ago

ghost commented 2 years ago

Please consider a release AppImage package along with zsync update file and OpenPGP signature.

blitzmann commented 2 years ago

Huh, looks pretty neat. Might be something I can tinker with.

ghost commented 2 years ago

This is good for those that don't want to tinker with Python and dependencies such as wxWidgets, the only alternative for them is to run the Windows package in Wine if they want a contained package. It can also be easily sandboxed and run as a portable.

wereii commented 2 years ago

This could be a good alternative for Arch, until wx is fixed (#2391)

blitzmann commented 2 years ago

Well, I can't get pyfa to run in my ubuntu image even due to wxpython failing to import things. I'll keep tinkering with it to get it working, then look into getting it packaged via AppImage. No promises tho ;)

wereii commented 2 years ago

I have played with this a little bit. python-appimage which makes packaging python packages into appimages very easy, can't be used because pyfa is not a valid python package and just adding setup.py/cfg won't do it (directory structure would have to change).

EDIT: It might be possible to use the python-appimage tool to just get a basic working python appimage, extract it, put whole pyfa repo somewhere, point the entry point to it, repackage and ... maybe? More research needed.

wereii commented 2 years ago

I made it work:

https://github.com/wereii/Pyfa/tree/appimage/appimage

Works on my machine as well as on one other, ArchLinux machine.

blitzmann commented 2 years ago

@wereii can you make a release on your fork with the .appimage file? I'd like to test the final result.

The steps looks pretty similar to what I was attempting, I just wasn't ever able to get wxpython to build unfortunately. Could be because I'm attempting via WSL, as well as I probably didn't have all the dev dependencies (it's been a while since I've tried to run this on linux), so I'll have another go in an actual VM probably tonight

wereii commented 2 years ago

Here it is https://github.com/wereii/Pyfa/releases/tag/v2.39.2

I wasn't able to build the exact version of wx from requirements.txt either, something about missing pathlib2. So I used wxPython <4.1 (see requirements.txt in that branch) which is 4.0.7.post2 and that seems to work.

blitzmann commented 2 years ago

Thanks for the info.

245MB is steep, I wonder if there's some tweaking we can do. I know that pyinstaller config (the packager for windows and mac build) excludes some specific modules that aren't actually needed but are usually part of the dependencies.

As for testing the image out... this is produced on both my Ubuntu WSL as well as my Ubuntu live CD via VM

image

I'm probably missing some dependency, but I figured the point of appimage would be that it's self contained.

ghost commented 2 years ago

I also get this on a fresh VM install of Mint 20.3


$ ./Pyfa-x86_64.AppImage 
Traceback (most recent call last):
  File "/tmp/.mount_Pyfa-xWEuW3f/opt/pyfa/pyfa.py", line 27, in <module>
    import config
  File "/tmp/.mount_Pyfa-xWEuW3f/opt/pyfa/config.py", line 4, in <module>
    import wx
  File "/tmp/.mount_Pyfa-xWEuW3f/opt/python3.8/lib/python3.8/site-packages/wx/__init__.py", line 17, in <module>
    from wx.core import *
  File "/tmp/.mount_Pyfa-xWEuW3f/opt/python3.8/lib/python3.8/site-packages/wx/core.py", line 12, in <module>
    from ._core import *
ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_Pyfa-xWEuW3f/opt/python3.8/lib/python3.8/site-packages/wx/libwx_gtk3u_core-3.0.so.0)

wereii commented 2 years ago

As far as I know, AppImage is more like executable zip, it does try to "contain" it's stuff but it's not... complete, and this error is nice example.

ghost commented 2 years ago

As far as I know, AppImage is more like executable zip, it does try to "contain" it's stuff but it's not... complete, and this error is nice example.

Well, you cannot include the entire distro in the AppImage that is why you would rely on other standards for a base install so you don't have to include everything.

wereii commented 2 years ago

I had flatpaks and snaps in mind, which do sandbox more then AppImage (afaik).

ghost commented 2 years ago

I had flatpaks and snaps in mind, which do sandbox more then AppImage (afaik).

AppImages can use firejail and bwrap. With that method you can use any sandbox you wish and not chained to bwrap only with Flatpak afaik. Also, AppImage allows portable usage (files don't go to an install HOME XDG locations rather they go do the local portable location). You shouldn't imo bundle a sandbox with a packaging system, they are two distinct responsibilities, that blobifies the technology and also goes against the principles of separation of responsibilities and replacability. By blobifying that you put too much power into the hands of fewer and turns it into blob distro where you have to throw out large chunks to replace a smaller chunk (for example, wishing to use Flatpak with a different sandbox technology other than bwrap, now Flatpak have control over your sandbox choice). You lose the power of choice by blobification.

There is also MAC (Mandatory Access Control) facilities such as AppArmor.

The issue here is your dependencies, not the packaging system.

wereii commented 2 years ago

The issue here is your dependencies, not the packaging system.

I know that. I didn't say different packaging is needed.

Let's get back to the issue at hand. wxPython gets built against the building systems glibc, what are the solution? also package the glibc? That's probably going to explode the size even more.

Though, the alternative would be to make a appimage for most used glibc versions out there, probably not feasible.

ghost commented 2 years ago

Perhaps this may help? https://discourse.appimage.org/t/specify-required-glibc-version-in-appimage/2413

wereii commented 2 years ago

Well, let's try https://github.com/wereii/Pyfa/releases/tag/v2.39.2docker

ghost commented 2 years ago

Well, let's try https://github.com/wereii/Pyfa/releases/tag/v2.39.2docker

That works on Mint 20.3

blitzmann commented 2 years ago

This also works for my on Ubunutu 18.04 on WSL, at first glance. This is excellent stuff!

I can start looking into integrating this into the build process on AppVeyor. I'm unsure what they have available in terms of distros to use. But I'm sure I can get it figured out. @wereii unless you object, I'm going to be forking off your branch so that you retain commit credit, and tweaking it from there to get it working with appveyor

wereii commented 2 years ago

Oh yeah, do whatever you want with it. Though, if I had to do it again I would make a shell script, not Makefile.

Also, there is a problem that building it in Docker requires special permissions and mount because of fuse, I am afraid this might not work thru CI.

-------- Original Message -------- On 18 Mar 2022, 02:56, Ryan Holmes wrote:

This also works for my on Ubunutu 18.04 on WSL, at first glance. This is excellent stuff!

I can start looking into integrating this into the build process on AppVeyor. I'm unsure what they have available in terms of distros to use. But I'm sure I can get it figured out. @.***(https://github.com/wereii) unless you object, I'm going to be forking off your branch so that you retain commit credit, and tweaking it from there to get it working with appveyor

ghost commented 2 years ago

Also, there is a problem that building it in Docker requires special permissions and mount because of fuse, I am afraid this might not work thru CI.

You can use --appimage-extract-and-run option on an appimage so it won't need to mount the squashfs using FUSE.

See here https://docs.appimage.org/user-guide/troubleshooting/fuse.html#fallback-if-fuse-can-t-be-made-working

blitzmann commented 2 years ago

I think I have it building correctly on my Ubuntu 18.04 distro, which is the distro that appveyor would use. Probably going to have to pre-build the wheel and upload it to my personal repo, and then use the makefile to download it

Also dropped the python / wxpython down to 3.7 / 4.0.6, simply because that's what the other builds use, and it would be good to keep everything targeted with the same versions.

I think we'll get there :D

I'll be providing a test file once I have it building in CI itself

blitzmann commented 2 years ago

AppVeyor build https://ci.appveyor.com/project/pyfa-org/pyfa-f3suj/build/job/us40egigd9vu3shd

Download: https://transfer.sh/x1xDHO/Pyfa-x86_64.AppImage

Can you guys please check to see if this works on whatever distros you have available? There's still a few tweaks to be made, but this is the first successful build

Thanks!

ghost commented 2 years ago

Can you guys please check to see if this works on whatever distros you have available?

AppImage launches on Mint 20.3 LTS (downstream from Ubuntu 20.04 LTS)

wereii commented 2 years ago

Also works on Manjaro (so pretty much also works on Arch).

blitzmann commented 2 years ago

I've got the makefile converted to commands in appveyor config, along with the various other tweaks that the other platforms packaging does (compiling locales, dumping version, etc).

The version dump exposed an issue where wx.html2.WebView wasn't implemented (because of the correct version information, the update notification window tried to launch and failed). This is because the build environment needs a webkit-dev package for wx to include it in it's wheel build.

I've got it working locally now, there's still a text formatting issue that I'm noticing

image

Additionally... I'm not sure why we use wx.html2.WebView. I feel like we don't need a full rendering engine, we're only handling simple html and not something like a full client side web app. [wx.html.HtmlWindow](https://docs.wxpython.org/wx.html.HtmlWindow.html#wx-html-htmlwindow) should be all we need. /shrug