Closed ghost closed 2 years ago
Huh, looks pretty neat. Might be something I can tinker with.
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.
This could be a good alternative for Arch, until wx is fixed (#2391)
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 ;)
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.
I made it work:
https://github.com/wereii/Pyfa/tree/appimage/appimage
Works on my machine as well as on one other, ArchLinux machine.
@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
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.
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
I'm probably missing some dependency, but I figured the point of appimage would be that it's self contained.
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)
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.
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.
I had flatpaks and snaps in mind, which do sandbox more then AppImage (afaik).
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.
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.
Perhaps this may help? https://discourse.appimage.org/t/specify-required-glibc-version-in-appimage/2413
Well, let's try https://github.com/wereii/Pyfa/releases/tag/v2.39.2docker
Well, let's try https://github.com/wereii/Pyfa/releases/tag/v2.39.2docker
That works on Mint 20.3
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
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
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.
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
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!
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)
Also works on Manjaro (so pretty much also works on Arch).
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
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
Please consider a release AppImage package along with zsync update file and OpenPGP signature.