Clojurians Log v2

Clojure on Windows can be really hard to get working. Very frustrating to read that thread.

The MSI generally works for folks who don't/can't use WSL2 but neither of those is an "official" out of the box solution.

It’s official enough to be what is recommended here for non-WSL: https://clojure.org/guides/install_clojure#_windows_instructions

Yeah, that's what I said on Reddit.

Last time I setup Clojure on a Windows machine, though, the MSI wasn’t enough. I am a Windows noob so probably holding things wrong, but I resorted to digging for the exe distribution on github and then rename that to clojure.exe and place it in my PATH.

Wow... I've installed via the MSI multiple times and It. Just. Works. on PowerShell...

But, yeah, Windows is pretty developer-hostile IMO. The only reason I switched to Windows from Mac was because of WSL2.

I agree that Windows is annoying and developer hostile. I also agree that we should support Windows well. I spent some time and different conferences this summer, including attending some workshops. At one workshop at a Java conference, over half the room was on Windows (I counted the raised hands.) At the Clojure workshop Jarrod lead, about 1/4 of the room was on Windows.

I'm going to be focused on understanding the "getting started" situation better over the next couple of weeks as I prep for the Clojure workshop at Clojure South. I have Windows, Mac, and Linux, and I'll be trying out different installation pathways. I'll document what I find.

I need to put together a formal announcement and sign up process, but heads up, I'm organizing a working group to focus on the tooling situation surrounding the getting started experience. I'll be posting a public call for participation as soon as I have a chance to write up the vision and set up a sign up.

I think the (unofficial) MSI is a good option -- but it needs some caveats and click-to-keep around security warnings -- but there's a general friction that a lot of projects are not tested on Windows, only macOS/Linux, and you can run into all sorts of weird errors because of that. The basics do all work at this point: MSI install, clojure -Ttools install-latest :lib io.github.seancorfield/deps-new :as new, and then clojure -Tnew app :name foo/bar, cd bar, clojure -T:build ci etc...

(FWIW, this tended to be the opposite problem in the CFML community I was in before: a lot of stuff was built for and run on Windows and didn't run on macOS/Linux!)

Oh the irony about the CFML situation! I'm cracking up, but I understand.

Yes. Windows needs more love, and I think it's important to keep Windows a good experience if we would like more Java devs (at the very least) to try Clojure out.

Just a couple points: • re the officialness of clojure-msi - I consider this to be an official way to install Clojure CLI (in addition to *nix ways on WSL). • The CLI powershell impl is dead and will be removed. • I am open to the idea of even making deps.clj the primary impl of the CLI and killing the bash version (but lots of follow-on questions to that idea). • The Clojure survey has consistently shown WSL use to be 50/50 among current Clojure windows users (not necessarily reflective of the greater Windows dev ecosystem). It is possible for us to conditionally ask questions in the survey only to Windows users, these would be good ideas. • While the CLR question is interesting, an answer is necessary for JVM Clojure regardless, and that’s going to be the primary answer on http://clojure.org. • A consistent problem in this space has been understanding what is “natural” or normal for (particularly non-WSL Windows devs. While we could build bridges and officialness to Scoop or Chocolatey or any of the many other answers, it has been hard to know what is really the best answer. I don’t think “all” is the right answer. A survey of what other Java-based language communities do would be useful.

@neumann I make sure my tools work on Windows based on the feedback I get. I have a dedicated Windows PC for testing Windows issues. It's not my daily OS though

I saw David Miller's post and am thinking aloud... He might be the best placed to know how to make Windows "getting started" better, for Clojure (with both .NET/CLR and JVM). I also wonder about sponsor appetite to fund him to do this... Windows is an eye-wateringly giant development platform, after all. https://clojurians.slack.com/archives/C06MAR553/p1756600191785569

I only know of his work from afar, but he's been a rock-steady shipper of Clojure itself.

I think "lean on Java" is the right approach, which I think @borkdude is already doing. Windows is pretty much a first-class citizen, same as linux and osx, in the Java world. Try to get off the platform-specific bash and powershell scripts, and lean on portable java io libraries instead.

deps.clj also lists another easy installation method on Windows:

Windows:

C:\Temp> PowerShell -Command "irm " > install_clojure.ps1
C:\Temp> PowerShell -f install_clojure.ps1
C:\> deps.exe
Clojure 1.10.1

user=>
To install deps / deps.exe as clojure / clojure.exe on your system, add the --as-clj flag:

$ ./install_clojure --as-clj

Agree about leaning on Java. It’s a requirement anyway (for JVM Clojure and ClojureScript). This goes for user instructions too. 1. Install Java. Still, a lot of the tooling relies on clojure to be on the PATH. So if the getting started story was like: 1. Install Java 2. Run this command to install clojure on your Path: java …. ◦ This would install a file that uses java to implement the Clojure CLI, which will make it a bit slow to start, but it should just work ◦ The guide should also make it easy to understand how to speed up startup time, using deps.exe. 3. Continue with cross-platform instructions that rely on clojure/clj…

> For CI installations: Github Actions has setup-clojure which manages clj / clojure fine on Windows (using deps.clj as well) I can confirm this. It is super straight-forward.

This would install a file that uses java to implement the Clojure CLI,

Which is fantastic (and extra nice for Calva which uses this). We have all the pieces. This is hopefully mostly about communication, plus some glue maybe.

Cursive also uses deps.clj btw ;-)

I could translate deps.clj to Pure Java so you can just download deps.class as a class file and execute it with Java. But I'm not sure if this would improve the easiness. It would be a bit faster in startup time for the non binary cases. But then it won't run in babashka from source anymore, which is how I got started with deps.clj in the first place :) I wanted to see if I could translate the clojure bash script to babashka.

On scoop, I also think having it as a requirement is not a big deal, same as assuming people have brew installed. "Blessing" the community maintained bucket (brew "tap" equivalent) https://github.com/littleli/scoop-clojure is another matter however, I see that the core team maintains the brew tap.

> But then it won’t run in babashka from source anymore It sounds like a stiff price to pay if “a bit faster in startup” is the only gain. Not sure that is what you are saying, but if it is, then I think we can accept the slower startup time, because the user will also get the information about how to improve that by installing deps.exe as clojure.

> On scoop, I also think having it as a requirement is not a big deal, As a seldom-user of Windows, this doesn’t chime with me. 😃 I recall having had problems understanding how to get scoop installed. I think “lean on Java, while also making sure that scoop works” is better than “require scoop”.

This argument makes as much sense as “as a seldom user of macOS I don’t want to use brew”. Fine, then download a script yourself (posted above)

Right, maybe requirement was not the right word, but having it as the first-choice installation path that you communicate to users. The path that is the most likely they end up with a correct installation, with the fewest instructions. To install clojure on windows, open a powershell prompt and:

# to install scoop
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri  | Invoke-Expression

# if you don't have git version control system installed
# it is required for adding new external buckets to your scoop installer
# you can skip this step otherwise
scoop install git

# add scoop bucket for Java
scoop bucket add java

# add scoop bucket with extras, here there is a dependency on visual studio redistributable 'extras/vcredist2022'
scoop bucket add extras

# add scoop bucket for clojure build
scoop bucket add scoop-clojure 

# install TCK certified Java runtime and compiler if you need to (optional)
scoop install temurin-lts-jdk

# install official clojure tools
scoop install clj-deps

> This argument makes as much sense as “as a seldom user of macOS I don’t want to use brew”. That’s why I qualified it. I mainly wanted to share my experience about installing it. I don’t know what scoop’s standing is on Windows. Homebrew is commodity for a developer on Mac.

> to install scoop Wow, I wish I had found this when I struggled last time. 😃

This is copy pasted from the scoop website and the clojure scoop bucket btw.

It’s great that it is this straight-forward. I still think we should start with Java-only as option 1.

The Java-only recipe probably can be made totally cross-platform too. Only the Install Java part needs to be separate.

You know this whole thread is confusing me even though personally, I'd much sooner chew my own fingers off than touch Windows for development. "java only" is so obviously self-limiting, because, well, the clojure-clr get started instruction is literally this... > The easiest and recommended method is to install ClojureCLR as a a dotnet tool. Or you can get a zip from Sourceforge and do whatever you like.

dotnet tool install -g Clojure.Main

I don't think the path of least requirements should be the 1st recommended path either. I think the recommended path should be the path that you are using long term. It's probably confusing to recommend some alternative method first which requires people to change later if they want to have the more common setup.

But if people get stuck, it's great if there are alternatives. You can list multiple ways

@adityaathalye in no way is the ecosystem of clojure-clr big enough to recommend for regular users interested in clojure. That would be a step in the wrong direction, giving the impression that using Clojure in Windows is gimped from the get go.

Again, Windows is a first class citizen in the JVM world. No reason to introduce them to a way more limited variant of Clojure.

I think JVM or CLR Clojure are different stories.

> I don’t think the path of least requirements should be the 1st recommended path either. I think the recommended path should be the path that you are using long term. It’s probably confusing to recommend some alternative method first which requires people to change later if they want to have the more common setup. Totally fair and valid point. Though to me the only difference is what clojure “binary” you have. So your setup doesn’t really differ much. Just how you get there. I could be missing something, of course.

> the path of least requirements This is not my position... It is "Please, let's ask the Windows guys what they think should be the recommended path".

These discussions have happened in the past in #clj-on-windows. The conclusion then was: people want a click-through installer, which then became clj-msi based on deps.clj.

If you ask 1000 Windows devs I'm sure you'll get several other opinions

I agree we should ask. And we should do Ux testing on whatever paths we design.

Acknowledged... I don't have a lambda in this fight and will happily defer to the opinion of concerned parties. > in no way is the ecosystem of clojure-clr big enough to recommend for regular users interested in clojure Tactically, sure. Strategically (because community-development is strategic), this begs questions like... Okay, so, Nu is financing JVM/Clojure. Who is not financing CLR/Clojure? Why not? What will get that to happen? Heavy skew to JVM/Clojure is specifically a Rich Hickey constraint, not a Clojure Community constraint. One person can do only so much deep expert work in the guts of a runtime.

> If you ask 1000 Windows devs I'm sure you'll get several other opinions Once again, emphatically not what I am saying. I am saying the opinion of the CLR maintainers matters... what they can make work for all those 1,000 developers. Same as is the case with clojure core and JVM Clojure.

And further, what can be done to help them achieve that goal.

It’s great if the ClojureCLR option is presented so that you don’t miss it when you ask “How do I get started with Clojure on Windows?“. But I don’t think the ecosystem is ready for it being the main option. For people who have reasons to target the CLR it is fantastic. And very easy to get started with, to my experience.

For people who have reasons to target the CLR it is fantastic.

--- And that's all I'll say on the subject, because I'm out of my depth and circling the drain now 😅 ---

That's a different topic I think. This thread was more about the beginner experience. I think clojure-clr on the other hand would be completely "frontier" stuff, where even experienced Clojure users would be left struggling with issues no one else previously ran into.

Haha, yeah, at least I highjacked the topic to mean what should be our answer to the question: How do you get started with Clojure on Windows? 😃 Super happy that the CLR topic was highlighted, because the need for Clojure is big there (even if it doesn’t show in demand yet, but that goes for JVM Clojure as well.)

Re: Homebrew being a commodity for developers on macOS -- is it tho'? Or is that confirmation bias because you use macOS and rely on it heavily? Homebrew has some serious philosophical issues that don't always sit well with how Clojure (or Java) want to operate. That's why we have a non-central tap for Clojure: the default tap forced the latest version of OpenJDK blessed by the Homebrew folks on users -- because that's how the Homebrew folks think by default: you ask for X, you get the latest version of X and the latest version of all its dependencies, no matter what you previously had installed, unless you set various env vars and perform certain incantations to defeat that -- which gets us into non-beginner territory. That's not to say that for macOS users the easiest path is something other than brew, it's just worth considering that just like Windows users might not have Scoop installed, so macOS users might not have Homebrew installed (I resisted it for years and used the shell script install approach for everything so I could control the versions I got). There's also the issue that brew update clojure (or is it brew upgrade clojure?) doesn't reliably update the Clojure CLI and many users seem to have to remove/uninstall their current version and then install the new version, which seems to be a regular footgun for users :( Right now, security warnings and app signing issues aside, the MSI is the most straightforward approach on Windows, IMO. I've used it repeatedly on multiple machines. It seems to install or update as appropriate, when I use each new version of the installer (I installed 1.12.2.1565 with it yesterday on Powershell, as an update to an earlier version). It sure would be nice if the installer was signed etc so that downloading it seemed less dangerous... It's also worth noting (again?) that for a beginner on Windows, there are all sorts of tooling quirks and footguns ahead due to weird quoting of EDN CLI arguments and pathing etc -- see https://clojure.org/reference/clojure_cli#quoting -- and a lot of Clojure/Script projects are not tested on Windows and some of those stop a beginner in their tracks. I'd love to know what uptake WSL2 has among developers on Windows in general -- because that's gets you into the mainstream (for Clojure/Script), well-tested Linux world where "all" projects should just work and all the installation instructions etc are aimed/tested. I agree with Adi that we need the input of more "regular" Windows users (developers) on this -- and we might want to ask outside the Clojure community or at least focus on complete Clojure beginners who've perhaps never even installed Java on Windows but are curious about Clojure...

(sorry, that was longer than I intended -- and highlights my years of annoyance with brew 🙂 )

I think Clojure has good potential to be introduced gradually and be used for various small internal "intranet" tools / utilities, for various data-pipeline tasks, etc, where a single "programmer" (whatever their current role) can add a lot of value. Assuming most such potential users can choose to have WSL2 installed in their corporate systems is already one assumption too many, IMO. It could be just my experience, but sysadmins in such Windows shops are overly security-paranoid to even consider it. (most likely they won't understand the security implications, and that's reason enough to reject it) So, not in any way a scientific estimate, but I would assume the vast majority of those using WSL2 have admin privileges in those systems. So already, you lose a good chunk of potential users.

Agreed. I wonder how many such "Enterprise" Windows systems have Scoop installed? Probably very few (since it would allow unfettered installation of software, which those corporate shops are specifically trying to control).

They wouldn't have it installed, but Scoop's approach works the same as installing any other portable application as a user without admin privileges.

@gentkr And the MSI approach requires admin privs? (I haven't worked in a locked-down Windows env for over 30 years at this point, but I have experienced it way in the past at two companies)

@seancorfield no the MSI approach doesn't necessarily require admin privileges (it all depends on the application being installed). I favored scoop simply because you can give a simpler recipe to install all of clojure's dependencies, and clojure, in one place with relatively simple to follow instructions. (and later on it's just scoop update clj-deps to get the latest version)

To summarize, I see these as different choice points: 1. Standard Windows vs WSL (Linux) 2. JVM vs CLR 3. Standalone script/binary vs installer vs package manager (eg. Scoop) 4. CLI: Powershell script vs deps.clj Of course, those are not all independent choices—some choices imply others. There are some areas that need research: 1. Is WSL common now? Is it common for Windows devs to use it? 2. What deployment platform are windows devs targeting? Windows? Linux? 3. What kind of application development is popular for devs using Windows? Backend services? Desktop apps? Web frontend? Also, I’d love to gather the info from this thread and put it in a useful form somewhere. That would help spell out the options clearly. We can discuss which paths might benefit from some work.

For what it's worth, I've had a very smooth experience using scoop on Windows, even on restricted corporate laptops. But I was already a user of scoop and checked if there was a clojure bucket, I don't know how discoverable it is otherwise.

Thanks for that info. I’ll try it.

Yes, Scoop is good but I hadn't even heard of it until the Clojure bucket was created - and it's yet another tool to install, if you don't have it already.

Compared to the alternatives it has the most focus on "user local installations". I think that's something that makes it suitable for a project like clojure that might not have that many established Windows users. All kinds of stupid things trip up windows antivirus software these days.

I think scoop installs the PowerShell script? I have never gotten that to work on any Windows machine I have tried. (The reason I as a Windows noob tries this so often is that I now and then need to verify how Calva works on Windows and it always starts with some hours in install hell before I get it working.)

No scoop uses borkdude's implementation.

@borkdude have you done much on Windows?