Feature request: Flatpak

[Beth Claire]

Flatpak is a format for packaging Linux desktop applications that can work on most distros using a single binary.  Given the difficulty of packaging Sagemath for each distro, and the difficulty of updating existing Sage packages to work with newer versions of distros, I think having a flatpak package of sagemath would make it easier to get the latest version of Sage running on as many systems as possible.

--Beth

[Volker Braun]

flatpak is designed for gui apps, registering a desktop icon and so on. To really make use of it we'd need at least a small gui app that then lets you start/stop the jupyter server and/or launch browser windows. 

If you just want to run Sage then there is already a one-liner podman / docker command to download and run it (and with podman any user account can do it, no permission setup needed):

 podman run  -it sagemath/sagemath

[318...@gmail.com]

Flatpak actually can handle CLI-only apps: for example, see mosh or appstream-glib.  They are hidden on the Flathub website, and that is by design.

But yes, what I really want is an any-distro way to easily launch Sage and a Jupyter notebook in a browser.  

[Samuel Lelievre]

2021-04-18 08:17:31 UTC, Volker Braun:

flatpak is designed for gui apps, registering a desktop icon and so on.

To really make use of it we'd need at least a small gui app that then

lets you start/stop the jupyter server and/or launch browser windows. 

Marc Culler's SageMath-macOS app could provide inspiration for that.

If you just want to run Sage then there is already a one-liner

podman / docker command to download and run it (and with

podman any user account can do it, no permission setup needed):

 podman run  -it sagemath/sagemath

 I installed podman under macOS using Homebrew by running

```

$ brew install podman

```

and I then got the following error running the command above:

```

$ podman run -it sagemath/sagemath

Error: cannot connect to the Podman socket, please verify that Podman

REST API service is running: Get "http://d/v3.1.2/libpod/_ping": dial

unix ///var/folders/fp/.../T/podman-run--1/podman/podman.sock:

connect: no such file or directory

```

Seems I'm missing one step to get the REST API service running.

[Jerry Caligiure]

Hello! I'd really like to get this working on flatpak. I'm trying to sandbox off applications from the system in Linux, and flatpak is an easy way to do that.

I'm thinking we could use electron (https://www.electronjs.org/) to create a gui if needed, but like stated previously you don't *need* a gui, you can just have

a socket open that the browser can point to. Is there any work that has been done on this? I've searched the github issues as well as this group, and haven't seen any work on this yet, only this post and one from like 2015.

Thanks,

Jerry Caligiure

[Dima Pasechnik]

On Sun, Feb 9, 2025 at 11:30 AM Jerry Caligiure <caligi...@gmail.com> wrote:
>
> Hello! I'd really like to get this working on flatpak. I'm trying to sandbox off applications from the system in Linux, and flatpak is an easy way to do that.
> I'm thinking we could use electron (https://www.electronjs.org/) to create a gui if needed, but like stated previously you don't *need* a gui, you can just have
> a socket open that the browser can point to. Is there any work that has been done on this? I've searched the github issues as well as this group, and haven't seen any work on this yet, only this post and one from like 2015.

As far as GUIs go, we do have a working GUI - using
Jupyter/Jupyterlab, i.e. Jupyter notebooks, run either in a browser
(talking to either a local Sage install, or to a remote/VM one), or
ditto in VSCode (again, talking to either a local Sage install, or to
a remote/VM one).
E.g. on windows one can run a native VSCode Jupyter session talking to
Sage running in WSL.
The installation is a bit rough right now, as historically it came up
using a fully vendored jupyter, and still suffers from various
glitches (mostly installation related) when an external Jupyter is
used instead.
This is something which needs work badly, and such work is more than welcome.

I don't know much about flatpak (beyond hearing complaints about
flatpaked web browsers being deficient in various ways) to
meaningfully comment on flatpack

HTH,
Dima

>
> Thanks,
> Jerry Caligiure
>
> On Sunday, April 25, 2021 at 2:53:03 PM UTC-4 Samuel Lelievre wrote:
>>
>> 2021-04-18 08:17:31 UTC, Volker Braun:
>>>
>>> flatpak is designed for gui apps, registering a desktop icon and so on.
>>>
>>> To really make use of it we'd need at least a small gui app that then
>>>
>>> lets you start/stop the jupyter server and/or launch browser windows.
>>
>>
>> Marc Culler's SageMath-macOS app could provide inspiration for that.
>>
>>> If you just want to run Sage then there is already a one-liner
>>>
>>> podman / docker command to download and run it (and with
>>>
>>> podman any user account can do it, no permission setup needed):
>>>
>>> podman run -it sagemath/sagemath
>>
>>
>> I installed podman under macOS using Homebrew by running
>> ```
>> $ brew install podman
>> ```
>> and I then got the following error running the command above:
>> ```
>> $ podman run -it sagemath/sagemath
>> Error: cannot connect to the Podman socket, please verify that Podman
>> REST API service is running: Get "http://d/v3.1.2/libpod/_ping": dial
>> unix ///var/folders/fp/.../T/podman-run--1/podman/podman.sock:
>> connect: no such file or directory
>> ```
>> Seems I'm missing one step to get the REST API service running.
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/205f0e03-93f8-4b49-b85d-e94c6c6b3e01n%40googlegroups.com.

[Marc Culler]

On Sunday, April 25, 2021 at 1:53:03 PM UTC-5 Samuel Lelievre wrote:

Marc Culler's SageMath-macOS app could provide inspiration for that.

After having done some research on this, my preference would be to package Sage as an AppImage, and I have plans for doing that.  An AppImage needs to be relocatable, and I believe that the scripts I use for the macOS app to make it relocatable would be easily adapted to do the same thing on linux.  I have not built an AppImage for Sage yet, but as a warmup I packaged SnapPy as a linux AppImage, and that was successful.  It is very easy to work with AppImages.  They are not sandboxed in the way that a snap or flatpak is sandboxed (e.g. restricting where files can be read from or written to), which I view as a plus, but they do not need to depend on any local libraries other than the C runtime.

The Sage macOS app is technically a GUI app, since it opens one window which is used to launch Sage, but there is no GUI provided for Sage itself.  The GUI is a few lines of tkinter code which could be re-used on linux.  So my plan would be to make the linux AppImage work the same way as the macOS app, with essentially the same code.

 An AppImage is a single file which is an ELF executable (although you must run chmod +x after downloading it) and which also contains an appended (compressed) squashfs filesystem that includes all code and libraries needed to run the main program.  It works completely in user space and need not require any external system packages.  The AppImage can go anywhere (although ~/bin is a recommended location).  It can also be easily integrated with an XDG desktop system by just adding a .desktop file and an icon.  (The Snappy AppImage installs those two files if run with an option --install.)

Ideally one would  build the appimage on a manylinux docker image so that it would be compatible at least with 5 year old linux systems.

 The Appimage executable simply mounts the squashfs filesystem and execs the main program, which can be a script, from a standard location in the filesystem.  It requires FUSE to mount the filesystem, which unfortunately mans that it will not work on WSL since, supposedly, WSL does not support FUSE.

 

- Marc