Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add AppImage packaging for Yakut #87

Open
jrrutlan-amazon opened this issue Jun 22, 2023 · 6 comments
Open

Add AppImage packaging for Yakut #87

jrrutlan-amazon opened this issue Jun 22, 2023 · 6 comments

Comments

@jrrutlan-amazon
Copy link

Hello! I've been looking at ways of reducing the complexity of the install of Yakut and reducing the variance in the combination of Python/Yakut/dependencies for users within my organization. I've been playing with AppImage packaging and have been bundling a specific Python version, Yakut, deps, and our DSDL so that installing and being able to interact with our Cyphal nodes is as simple as grabbing the single file and running it in a terminal.

So far I've found that packaging Yukut on Ubuntu 20.04 for use on Ubuntu 20.04/22.04 is fairly simple. Packaging for use on a wider range of Linux platforms (e.g. those with older glibc etc than Ubuntu 20.04's) is trickier.

I think that including the build of an AppImage into the Yakut CI here, so that it can be downloaded from GitHub would be very useful for many consumers.

While such a build may not be able to take advantage of the deeper integration by including vendor-specific DSDL, or hardcoding the configuration of e.g. CAN interfaces, it would certainly reduce the surface area of versions of dependencies that a majority of users would experience and hopefully provide a useful "does the AppImage work for you?" response to troubleshooting questions.

Happy to discuss further and contribute my work so far.

@pavel-kirienko
Copy link
Member

I guess we could give it a try. How long does it take for an AppImage to launch? Doesn't it involve unpacking the resources beforehand? If yes, does it add any noticeable latency when invoking the command?

If the changes required for this are limited to just a new CI workflow, we can accept that easily. Otherwise we may need to weigh pros and cons.

@jrrutlan-amazon
Copy link
Author

Thanks for considering it. I think inclusion is as you say; a new CI workflow. I'll gather some performance observations and comparison next week so we can weigh it up more usefully.

@jrrutlan-amazon
Copy link
Author

Some initial data from my Ubuntu 20.04 laptop (Intel® i7-10850H)
time yakut with my system Python 3.8:
real 0m0.651s
user 0m0.664s
sys 0m0.734s

time yakut.AppImage:
real 0m0.273s
user 0m0.453s
sys 0m0.894s

So the initial load is roughly just over double. But my entry point script into the AppImage has an option to drop you into a shell, from where you can time yakut:
real 0m0.487s
user 0m0.615s
sys 0m0.927s

I'd guess that the latency regardless of being 'inside' or not is due to decompression from the SquashFS file system. There might be options to not compress the AppImage, and I can investigate those also if you think this load time is unacceptable.

@pavel-kirienko
Copy link
Member

pavel-kirienko commented Jun 22, 2023

I don't understand the numbers. Are you saying that running yakut takes 0.651 s while yakut.AppImage takes 0.273 s, over twice less?

@jrrutlan-amazon
Copy link
Author

Oh my mistake - I've got my labels the wrong way round. So the AppImage takes just over twice as long to load. For clarity, here is the correctly labelled result:

time yakut.AppImage
real 0m0.651s
user 0m0.664s
sys 0m0.734s

time yakut with my system Python 3.8
real 0m0.273s
user 0m0.453s
sys 0m0.894s

@pavel-kirienko
Copy link
Member

Okay. I think this is not entirely unreasonable, and those who care may always resort to the proper installation instead. Considering that the maintenance cost is negligible (just a single CI workflow), I think we should proceed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants