Rethinking Juliawin

[heetbeet]

Problematic aspects of Juliawin

• Currently releasing Juliawin from my home computer is not sustainable or auditable (from a security standpoint).
• Also, Juliawin needs to find a way to become somewhat cross-platform. My initial tests in https://github.com/heetbeet/juliawin/tree/moving-over-to-bash-centric-environment seems like the best way to go cross platform is to move all the glue over to bash, and to add GitSCM as a hard dependency for windows users (not ideal though, since GitSCM adds ~50mb dependencies).
• The code for Juliawin is a spaghetti mess with a mixture of both downloading and setting up the environment, making entry points to the portable applications, and doing portability cleaning and environment fixing. We need to fix this situation

Rethinking the model

I'm playing around with Github Actions and the following pipeline needs to be set up in order for this product to survive and not require constant maintenance:

Actionables

• Remove all code that downloads external artifacts and move this over to a Github Action build step
  • e.g. run choco install tcc to get tcc
  • e.g. get rcedit artifacts from https://github.com/electron/rcedit
  • e.g. use https://github.com/julia-actions/setup-julia to retrieve julia and then just copy it into packages
  • e.g. just pirate GitSCM directly from the %ProgramFiles% directory
  • e.g. run suisei-cn/actions-download-file@v1 to download and extract vscode and friends
• Maybe zip and keep a Github link for each program in packages/<program> so that you can retrieve it externally as dependencies when we want to
• Maybe add a simple commandline tool to do simple feature installations and removals
  • e.g. juliawin install [vscode/pluto/pycall/ijulia]
  • e.g. juliawin remove [vscode/pluto/pycall/ijulia]
  • e.g. juliawin upgrade [vscode/pluto/pycall/ijulia]
  • e.g. juliawin force-julia-version 1.6.3
• While we are inventing the wheel, we should probably just use julia from https://github.com/JuliaLang/juliaup to get all the julia versioning features
• Maybe use instruction configurations like a pluto.yaml or a vscode.yaml to do the feature installation dirty work (how do others do it?), add things like
  • Entry point wrappers + their icons
  • Code that needs to be run to install the feature and all it's dependencies
• Build a mechanism that can move the original packages/julia to packages/julia_backup and use it as a fallback when juliawin force-julia-version fails (do this only for the original julia that come with the original installer)
• Build ready made installers that have made a few feature choices on your behalf: steal everything useful to create exe installers from https://github.com/heetbeet/juliawin-create-releases/blob/main/scripts/make_release_from_scratch.py and chuck the rest
• Let this pipeline flow into Juliawin release cycle

Take away

• Juliawin started as a script that can be run on Windows without any dependencies and do all the downloading, unpacking and glueing together on the user's behalf.
• This model is very flawed and not ideal, you want everything that can go wrong be vetted in the build process, and give the user a clean installer to get things started.
• We gradually moved over to providing installers, but the code for generating these installers is a complete manual mess: https://github.com/heetbeet/juliawin-create-releases
• We should focus on being as lazy as possible for our implementation, use other good well-vetted projects like chocolatey, GithubActions, juliaup etc. to do the heavy lifting.

[RoyiAvital]

I would also add ability to upgrade a current installation.

[RoyiAvital]

By the way, Why bash and not PowerShell?