Right now we have three platforms: Windows, MacOS and Linux.
The binary created by make can easily be distributed as-is to other Linux users. Most Linux users are tech-savvy enough to know they simply need to place an executable onto their PATH, probably ~/.local/bin. We can probably create a .deb or .pkg file to make installation even more automatic but unless we manage to put our binaries into the package repository of major distributions I do not see any value in making this more comprehensive.
The binary created by our .\bin\build.ps1 script can also be distributed to other Windows users as-is but most Windows users have no experience in adjusting their environment variables to put the executable on their path. Right now we use the AdvancedInstaller script from the former decker-package repository to create a .msi script that places the executable somewhere the user wants and appends the target directory to the PATH environment variable.
Most Windows users lack access to relevant third party tools though and I do not see us putting yet another step (in the form of "install a package manager") as a hurdle towards potential users. The most important missing dependencies are ffmpeg and rsync - users who did not use LaTeX, gnuplot or graphviz before will not use it with decker so these are clearly optional. Both simply need to be downloaded, extracted and their new locations appended to the PATH. Issue is ffmpeg is prominently available inside 7z archives which means users also need to download and install 7zip before they can extract and install the library. rsync for Windows is easily available as cwrsync which comes with all necessary dlls in one zip file but the important step here is to PREPEND the bin directory to the PATH of the user because windows' own OpenSSL executable does not want to work together with the cwrsync's rsync executable - so it is important that the cwrsync ssh.exe is on the PATH BEFORE window's own. It also needs a crucial config file relative to the executables because else cwrsync doesn't copy the correct file permissions. This file is not distributed inside the default cwrsync zip.
All this can easily be done by the AdvancedInstaller : We can make it install a chosen version of ffmpeg and cwrsync together with decker into a chosen directory and do necessary adjustments to the PATH variable. We might need to check if there are licensing issues with this but it would remove two major headaches in one go for new users. The AdvancedInstaller script is not very thought through though: Installing decker multiple times (e.g. different versions) does repeatedly append values to the PATH, polluting the system a bit (not really detrimental but definetly annoying, especially if you want to clean up).
For MacOS Mario used the other scripts inside the decker-package repository to create a .pkg file. The only issue here is that we did not sign our software so users will be confronted with unfriendly warnings but they can be ignored if launched directly from the file explorer. Same thing happens on Windows btw.
Additional programs used by decker can be easily installed via pre-existing package managers on Linux and MacOS.
My recommendation is to take another look at the AdvancedInstaller script and improve it with some robustness, update capabilities if installing a new version and maybe distribute ffmpeg and cwrsync with it (if licenses allow) to make the user experience as smooth as possible. Installation on Linux and MacOS is already much more simple.
Places for distribution can stay on the wburg and tudo websites but I would suggest we also put downloads to the packaged release files into the decker-edu github pages.
Right now we have three platforms: Windows, MacOS and Linux.
The binary created by
makecan easily be distributed as-is to other Linux users. Most Linux users are tech-savvy enough to know they simply need to place an executable onto their PATH, probably~/.local/bin. We can probably create a .deb or .pkg file to make installation even more automatic but unless we manage to put our binaries into the package repository of major distributions I do not see any value in making this more comprehensive.The binary created by our
.\bin\build.ps1script can also be distributed to other Windows users as-is but most Windows users have no experience in adjusting their environment variables to put the executable on their path. Right now we use the AdvancedInstaller script from the former decker-package repository to create a .msi script that places the executable somewhere the user wants and appends the target directory to the PATH environment variable.Most Windows users lack access to relevant third party tools though and I do not see us putting yet another step (in the form of "install a package manager") as a hurdle towards potential users. The most important missing dependencies are ffmpeg and rsync - users who did not use LaTeX, gnuplot or graphviz before will not use it with decker so these are clearly optional. Both simply need to be downloaded, extracted and their new locations appended to the PATH. Issue is ffmpeg is prominently available inside 7z archives which means users also need to download and install 7zip before they can extract and install the library. rsync for Windows is easily available as cwrsync which comes with all necessary dlls in one zip file but the important step here is to PREPEND the bin directory to the PATH of the user because windows' own OpenSSL executable does not want to work together with the cwrsync's rsync executable - so it is important that the cwrsync ssh.exe is on the PATH BEFORE window's own. It also needs a crucial config file relative to the executables because else cwrsync doesn't copy the correct file permissions. This file is not distributed inside the default cwrsync zip.
All this can easily be done by the AdvancedInstaller : We can make it install a chosen version of ffmpeg and cwrsync together with decker into a chosen directory and do necessary adjustments to the PATH variable. We might need to check if there are licensing issues with this but it would remove two major headaches in one go for new users. The AdvancedInstaller script is not very thought through though: Installing decker multiple times (e.g. different versions) does repeatedly append values to the PATH, polluting the system a bit (not really detrimental but definetly annoying, especially if you want to clean up).
For MacOS Mario used the other scripts inside the decker-package repository to create a .pkg file. The only issue here is that we did not sign our software so users will be confronted with unfriendly warnings but they can be ignored if launched directly from the file explorer. Same thing happens on Windows btw.
Additional programs used by decker can be easily installed via pre-existing package managers on Linux and MacOS.
My recommendation is to take another look at the AdvancedInstaller script and improve it with some robustness, update capabilities if installing a new version and maybe distribute ffmpeg and cwrsync with it (if licenses allow) to make the user experience as smooth as possible. Installation on Linux and MacOS is already much more simple.
Places for distribution can stay on the wburg and tudo websites but I would suggest we also put downloads to the packaged release files into the decker-edu github pages.