Eclipse uses their homegrown installer project known as Oomph to provide an exe installer for windows users; might it be fruitful to investigate Oomph to see what it would take to write a Clojure installer? http://wiki.eclipse.org/Eclipse_Oomph_Authoring#Getting_Started I'm inclined to try my hand at this

hey, I was out of town this weekend and have not read the whole thread above. anyone have a summary?

discussion of quoting issues, enthusiasm from @chaos on the topic of an exe installer, and some other nuances

(plus what's on http://ask.clojure.org about the Powershell/Microsoft Gallery)

let me rephrase then - what (if anything) do I need to do to move the ball forward?

I'm interested in trying out Oomph for writing an exe installer unless you know of a reason that I shouldn't or wouldn't be able to. I'll just write it for myself and see how it goes, for my own experience. Sorry for making you feel obligated to respond to something

Hi @alexmiller here is a summary of the above thread. The subject of the discussion was a post of the below suggestion in ask Clojure, to put forward for consideration the deployment of the PowerShell ClojureTools to the PowerShell Gallery, that if sound, will trivially solve the tools installation problem on MS-Windows and bring them on par with what is offered for Unix based Os's. There was a debate in very good faith whether we want first class tools support for Windows and what benefit this will bring to Clojure. I have provided my view that first class support (on par with Linux) is a must and within reach and that how this will benefit the windows community enormously, other people suggested a best effort approach, as it has been so far, is good enough since there are other ways windows users can go to try Clojure out (deps.exe, WSL), while the Clojure core team might have other priorities for their resource allocation. The differences in arguments quoting was touched and how this complicates writing web instructions for both Unix and Windows, and was concluded that even if we move to deps.exe, the quoting issue still remains. There was also a discussion about the unique challenge windows user facing with Clojure tools nowadays in corporate environments, where restrictions are placed on what can be installed on their PCs (no .exe'cutables, sysadmins prefer MSI installations/PS modules), and this should be taken into consideration on any installation improvement attempts. We all agreed an .exe based solution would provide a better experience for windows users. (please do correct me if I misunderstood something, thanks) https://ask.clojure.org/index.php/12288/proposal-to-deploy-clojuretools-to-the-powershell-gallery

evaluate the above proposal if you could please.

> and was concluded that even if we move to deps.exe, the quoting issue still remains … but is vastly improved when shelling out to a clojure cli. I gave up trying to shell out to the clojure powershell module and moved to deps.exe.

The way I see it, we talked about 2 separate things: 1. choosing an installer tech (or techs) for Windows 2. evaluating the cli launcher implementation on Windows, currently the alpha PowerShell modules, but moving to something like deps.exe would have usability benefits. @alexmiller you might need an unbiased grid to evaluate pros/cons of alternatives. Trouble is finding someone to volunteer to do that.

well, I can do that :)

For the grid: one thing to check when choosing deps.exe or similar: what architectures are supported by Microsoft Windows (and Clojure) and does GraalVM native-image support all of those? So far I haven't heard someone ask for a binary for Windows on PowerPC and I don't think that MS supports that anymore, but it might be good to double check.

And the grid should probably have a column for just punting on native Windows support (at least from the core team) and just suggesting alternatives (WSL2 being one -- where "everything" CLI related just works but you need an editor setup that understand the remote/VM aspect of WSL2 -- and community solutions such as Scoop etc on one hand and deps.clj/`.exe` on the other)?

yep

here's a start: https://docs.google.com/spreadsheets/d/10YEzhe-lG6_8FBtcLpZ84ozayCsY9K74nbnTWAO0zrw/edit#gid=0 probably capturing some things wrong so please help me correct. I've separated the runtime from how it's installed - those seem at least partially orthogonal

One correction: quoting is also "orthogonal" to whatever solution you choose: .bat, .exe, .ps - it doesn't matter. (Perceived) quoting problems are the result of shell-specifics + demanding people to use quotes in CLI design

So quoting isn't better with .bat files than with the other ones

Description of deps.exe: doesn't depend on babashka: it's JVM Clojure compiled to native

deps.exe / deps.clj is the same Clojure code which can be run / compiled to different targets. The code is babashka compatible so it can run with JVM Clojure (and you can compile that to native image) but also run it directly with babashka.

Nowadays I don't think anyone uses that Clojure code as babashka script because deps.clj is a built-in of babashka (so part of the binary) now.

If you run bb clojure ... it uses deps.clj. But for the sake of this discussion, I think that is similar to deps.exe

The powerPC example was just a farfetched example but there may be other relevant architectures, that I'm not familiar with, don't know

Why is downloading an executable meh but downloading an executable installer consider safer? Both are executables?

I would also add a CI row or column to the installer part. Having to click through some GUI program on Windows CI might be problematic. I'd rather just be able to download something there which works without any installation

Btw, there is a Powershell based installer script for deps.exe: https://github.com/borkdude/deps.clj#quickstart

wrt to the powershell module, I think deploying it to the powershell gallery might address both security and system admin sec concerns (installation is done directly from the repo, no need to download separate installation script, option to install to the user directory is supported by the installation process, and it should feel "normal")

Are there any Windows sysadmins nowadays that don't use powershell for some reason?

We've had at least one person in this channel who didn't want to use powershell but I don't remember exactly why that was

(gotta go now catch some 💤 )

For WSL, (personal opinion) I would argue to the question "does it feel normal" (to windows users): no, and has some known annoyances/issues (interop between native win/wsl can be annoying, no native x win support on win10, opening an IP port takes non-obvious extra effort, does not work out of the box with corporate Web Application Firewalls, and possibly more based on the individual person's dev workflow). I have a most annoying bug with running Emacs on WSL due to the x windows server of choice, that whenever my computer comes back from power suspension, Emacs will crash. This is a known GTK bug well discussed that they won't fix.

> Are there any Windows sysadmins nowadays that don't use powershell for some reason? I don't do it professionally anymore, but my partner works at a large government agency in a cloud admin-ish role and using PowerShell for anything is a nightmare for her because their organizational policies require any powershell modules/scripts to be re-signed with an organizational code signing cert.

and regardless of the eventual installation method, I also agree w/ @lee's point that clj and clojure being some kind of executable object rather than pwsh aliases would have real ergonomic benefits