Overview of different approaches

[soehms]

Functionality we have in sum

This issue continues #1 (comment).

FYI: I made some major changes in my approach. I got rid of Docker Desktop replacing it by a custom WSL distribution based on Alpine Linux. This makes the installation much easier, faster and less resource consuming and reduces startup-time.

How do we want to proceed here?

We have five codebases:

A) the one by @saraedum, which is developed for flatsurf and installs Sage as a custom WSL distribution.
B) the one by @kwankyu, which is developed in the sage-binder repository and installs Sage as a custom WSL distribution, too.
C) the one by @soehms, which is developed as an example for a projects docker guide and installs Sage via Docker in a custom WSL Docker distribution.
D) the one by @tobiasdiez, which is developed via a native Windows build of Sage using meson (see sagemath/sage#38872 and #1 (comment) below).
E) the one by @culler, which is developed as an AppImage. Similar to A-C, it depends on the availability of WSL. A manylinux2014-compatible Linux distribution is required (see https://github.com/3-manifolds/sage_appimage/releases).

All except D) have in common that they need a working WSL installation and this is the hardest part of the installation and most sensitive to system requirements. Let me try to summarize what we have in total (please correct me if I'm wrong):

1. Installing WSL
    1.1 detection of state
        A) Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux /  VirtualMachinePlatform
        B) try .. catch  with wsl --install --no-distribution
        C) wsl --status
    1.2 installation
        A) Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux / VirtualMachinePlatform -NoRestart
        B) wsl --install --no-distribution
        C) wsl --install --no-distribution
    1.3 handling of reboot (if necessary)
        A) InnoSetup asks you to reboot and otherwise it doesn't continue. It adds the installer to the autostart so that the installation continues after the reboot.
        B) Print a hint that reboot could be necesarry.
        C) Query for reboot if it is necessary and perfom it if the user agrees. Give a hint that the installer must be restarted after reboot.
    1.4 detection that virtualization needs to be enabled in BIOS.
        A) -
        B) -
        C) Via result from wsl --import.
    1.5 Update WSL kernel
        A) Using msi wsl_update_x64.msi
        B) -
        C) -
    E) not supported, yet
2. Setting up the custom WSL distribution.
    A) Using wsldl to create a custom distribution for each Sage release from a tar-file created by Pixi (see link below)
    B) Using wsl --import to create a custom distribution for each Sage release from a tar-file exported from a Docker container.
    C) Using wsl --import to create a custom distribution with a running Docker daemon (Docker for Powershell) from a tar-file exported from a Docker container.
    E) not supported, yet
3. Installation method
    A) Install-Wizard created by Inno Setup
    B) Invoking a Powershell script
    C) Invoking a Powershell script
    D) not yet known
    E) manually, but easy if there is an appropriate WSL distrubution
4. Launching Sage
    A) Create three desktop icons to launch an IPython, JupyterLab or Bash environment to work with Sage
    B) Create two desktop icons to launch an IPython or JupyterLab environment to work with Sage
    C) Create one desktop icon to launch a special application which allows to install arbitrary Sage releases from registries on Docker Hub and launch Ipython, Jupyter-Notebook (Lab needs an adaption in our Docker images) or Bash environments to work with Sage.
    D) not yet known
    E) as for Linux inside the WSL-distribution

From a user perspective, there is hardly any difference between A) and B) (asuming equal resource consumption). Therefore, I think it makes sense to consolidate the two approaches. From a technical perspective, both approaches have different advantages:

A) Is implemented as part of installers for Linux, Mac and Windows and uses a common base via Pixi.
B) Is implemented in a more down-to-earth way and therefore easier to understand.

Is there a way to merge these two approaches? Maybe it would make sense to include 1.4 here as well. For C) it would be nice to have 1.5 and 3. (creating an install-wizard using Inno Setup) as per A). Is there a way to share the WSL installation across all four approaches?

[culler]

I am far from an expert in WSL or Windows, but on my Windows 11 laptop installing WSL2 with the standard ubuntu linux image required two steps:

1. Open powershell
2. type: wsl --install

It is hard for me to imagine that making a custom WSL installation could possibly be simpler than that.

To use the WSL ubuntu image later I would open the powershell and type wsl. That also seems about as simple as possible.

[tobiasdiez]

From a user's perspective, a simple installer that one has to only double click is the most convenient in my opinion.

The next question would be if the wsl distro image should install sage via pixi, docker, appimage or built-from-source. I think it's a good idea to discuss the merits of each approach, and then decide on one (or perhaps two) options so that we can concentrate our energy on having a well-maintained installer.

[kwankyu]

I want to comment on the "How do we want to proceed here?" question.

I think each author of different approaches is willing to maintain his installer for now. I don't think that "decide on one, concentrate the combined energy of all authors on the one approach" is realistic. I prefer gradual evolving.

The README may contain links to different installers, but the repo will contain the installer by @soehms. He will lead the project. He may take any merits of other installers into his installer, and others may help him. For example, if he decides to use pixi, then @saraedum may help. If he wants, he may use icons used in my installer. And so on.

In some day, if the main installer in this repo is best in all aspects, then other installers may be dropped from the README.

[soehms]

I am far from an expert in WSL or Windows

Me too!

but on my Windows 11 laptop installing WSL2 with the standard ubuntu linux image required two steps

In all the tests I ran a year ago on a freshly installed Windows, your second step didn't work right away. I tested on two Windows 11 Pro host systems (both running on older hardware on a second-generation i5). I also tested Windows 10 (Home and Pro) and Windows 11 Home (via Hyper-V virtualization) on these host systems.

If this doesn't work, a user without development and administration experience will be send into frustration (which would not be a nice welcome for a potential new Sage user).

It is hard for me to imagine that making a custom WSL installation could possibly be simpler than that.

Indeed, this step is much easier, but not really convenient.

To use the WSL ubuntu image later I would open the powershell and type wsl. That also seems about as simple as possible.

For people familiar with Linux this is true. However, this assumption is not true for most Windows users.

[soehms]

From a user's perspective, a simple installer that one has to only double click is the most convenient in my opinion.

+1

The next question would be if the wsl distro image should install sage via pixi, docker, appimage or built-from-source.

Regarding the WSL distribution, a question prio to this is whether we use a common Sage distribution for all releases, which can contain multiple Sage releases in one distribution (as is the case with C and is also possible with E), or whether we create a separate distribution for each Sage release (as is the case with A and B).

From what I understand about the native Windows build, it will be a while before we have suitable Windows binaries that cover all Sage functionality and can be built by CI for each release, right? Until then, I consider solutions that require WSL to be temporary. Therefore, we should only do things via WSL that don't require a lot of effort.

I think it's a good idea to discuss the merits of each approach, and then decide on one (or perhaps two) options so that we can concentrate our energy on having a well-maintained installer.

It's always a good idea to discuss before doing!

[soehms]

The README may contain links to different installers, but the repo will contain the installer by @soehms. He will lead the project. He may take any merits of other installers into his installer, and others may help him. For example, if he decides to use pixi, then @saraedum may help. If he wants, he may use icons used in my installer. And so on.

What I can offer is to create an installer, available from the release assets of this repo, that creates a WSL distribution called SageMath that is independent of the Sage release and integrates solutions C) and E). Upgrades of the AppImage to a new Sage release could be performed within the app attached to C). If everyone agrees, I can implement it. I have no preferences regarding the choice of icons.

In some day, if the main installer in this repo is best in all aspects, then other installers may be dropped from the README.

As mentioned, I consider the WSL solutions temporary (see also this sage-devel post). Once suitable Windows binaries become available, they should be accessible directly from the Sage installation pages. However, this repository can be maintained as an add-on as long as the installers offered as assets or advertised in the README file work.

[culler]

For people familiar with Linux this is true. However, this assumption is not true for most Windows users.

I am not convinced of that, but I don't think it would be hard to create a button which runs a script that does that job. However, I don't know how people can be expected to use sage without being willing to type commands and have responses printed to the screen.

[tobiasdiez]

Regarding the WSL distribution, a question prio to this is whether we use a common Sage distribution for all releases, which can contain multiple Sage releases in one distribution (as is the case with C and is also possible with E), or whether we create a separate distribution for each Sage release (as is the case with A and B).

Again from a user's perspective, is there any reason to use multiple sage releases in parallel?
That question also mostly touches on the update process, right? Probably it's easier for the installer to just ditch the old wsl image and install a new one, instead of running update procedures inside the wsl distro. On the other hand, the user might have put some files in the wsl...

From what I understand about the native Windows build, it will be a while before we have suitable Windows binaries that cover all Sage functionality and can be built by CI for each release, right? Until then, I consider solutions that require WSL to be temporary. Therefore, we should only do things via WSL that don't require a lot of effort.

Yes, it's a slow process, mostly because not all dependencies have (stable) windows build scripts... I hope by the end of the year I have a version that allows to start the sage shell. How much functionality is then actually working is another question.

[soehms]

but I don't think it would be hard to create a button which runs a script that does that job.

Exactly, but we should do that!

However, I don't know how people can be expected to use sage without being willing to type commands and have responses printed to the screen.

This isn't exactly the same! You can use Sage without knowing the Linux file system or Bash commands like chmod.

[soehms]

Again from a user's perspective, is there any reason to use multiple sage releases in parallel?

I think there are many user perspectives, and we should adress as many as possible. Some users prefer not to have a lot of junk accumulating on their computer, others may want to keep a previous release for a while until they're sure the new one won't be a regression for them (most relevant for UI changes, such as IPython upgrades). Every time I launch MS Teams, I'm asked if I want to revert to the old UI. I like this feature.

That question also mostly touches on the update process, right?

Yes!

Probably it's easier for the installer to just ditch the old wsl image and install a new one,

Regarding cases A and B, I agree.

instead of running update procedures inside the wsl distro. On the other hand, the user might have put some files in the wsl...

This would be implicit in C (since this is a feature of Docker) and easy to do in E (just file download and file deletion).

Yes, it's a slow process, mostly because not all dependencies have (stable) windows build scripts... I hope by the end of the year I have a version that allows to start the sage shell. How much functionality is then actually working is another question.

Where is progress tracked after sagemath/sage#38872 was closed?

[tobiasdiez]

I've now opened sagemath/sage#40676 to track progress on the native win build. The next step would be to have all dependencies with suitable windows build on conda (eg ntl, maxima). Then to have the import of sage.all succeed even though some dependencies are missing. Then the tests should run in principle, which would give a first valid assessment on how much of the sage codebase is working correctly on Windows.

[gvanuxem]

Hello,

I use WSL2 since some times. Before WSL2 was out. Here is another way that can be of interest:

What about adding another very simple solution:
First install WSL2:

https://learn.microsoft.com/en-us/windows/wsl/install

The manual way, can be better, I personally use it:

https://learn.microsoft.com/en-us/windows/wsl/install-manual

The second way you can choose your distribution from the Micro$oft store. Or in the first way instead of using
wsl --install your can specify the distribution you want using wsl --install kali-linux or 'debian' for example if you prefer.

After log in your distribution, normally a clickable link (it sets some interesting things) is provided in the start menu or use in cmd or PowerShell the command: wsl. A link is also provided in PowerShell:

After you just have to follow the official very simple "install from conda-forge" official instructions:

https://doc.sagemath.org/html/en/installation/conda.html

Regards,

Greg

[GMS103]

What I can offer is to create an installer, available from the release assets of this repo, that creates a WSL distribution called SageMath that is independent of the Sage release and integrates solutions C) and E). Upgrades of the AppImage to a new Sage release could be performed within the app attached to C). If everyone agrees, I can implement it. I have no preferences regarding the choice of icons.

@soehms
+1
I think this would be very useful.
In fact, I was trying to do it for E) following the approach in A).

[dimpase]

As mentioned, I consider the WSL solutions temporary

we have upstream parts which need porting to Windows (even to mingw), the best known is GAP.
I think a good indicator of success here would be a GAP port to Windows (which is a desirable thing by itself).

Porting GAP to Windows is not easy, see gap-system/gap#4157
In a nutshell, GAP has a custom GC, tied up to the usual Unix/Linux memory model.
GAP has a port (HPC-GAP) which replaces their custom GC with Boehm GC, but this port isn't considered production quality. It also has an actively maintained and worked on port to Julia GC, to incorporate GAP into Oscar - but AFAIK Julia's GC is tightly integrated into Julia (Julia itself runs on Windows), so you can's just make it into a standalone Windows port of GAP.
Also, Oscar does need WSL, I don't know whether they have plans for a native Windows port. @fingolfin and @ChrisJefferson might say more on the latter.