Just Use MSYS2 You Say?

After I posted my announcement of the Windows Install Scripts for Real Programmers I received quite a lot of praise for the description. I should say that I write essays that describe my thought process when making a piece of software because so many people who study programming don't really know how to develop an idea. I try to go through my thoughts and design process to help them out, not necessarily to get the approval of other technologists.

I still do look at what other programmers say about the things I make because sometimes they have valid criticisms or ideas. This time though some of the comments about my approach are completely disconnected from reality. Here's just a few samples of some:

"Isn't this easily solved by VMs?"

What? A person just bought my course, they have a perfectly good working computer, and your answer to their setup problems is...install another computer that runs very slowly inside their computer?

"[VSCode + browser + docker or WSL2 image] = who cares? This article feels about 4 years out of date which is more a commentary on how fast the industry moves and how sometimes not even Google can burst your bubble."

Yes, that seems like a totally reasonable way to help beginners use their computer to make software. It's simple! First you install VSCode then spend then next 12 hours getting docker to run dev containers inside a WSL2 image (which is just a VM that can't talk to the internet) and TADA! You're ready to code...inside a VM that's inside a VM that's "magically" talking to their text editor. If some real person hadn't written this I'd have thought it was a TikTok Meme account.

"Windows is not the root problem. The root problem is people thinking Windows is acceptable."

I love how people say that I'm irrational for claiming that Windows is rarely supported in the world of programming and then two comments down is some dude literally demonstrating how much people hate Windows in the world of programming.

"Why are programing (sic) students having a hard time setting up thier (sic) environments? Shouldn't they have taken some OS 101 classes? At least know how to install software? I never went to college, but I assumed they would get you proficient in prerequisites first."

Clearly someone who actually read the essay, which is a staple of online programming discourse. I'll bet $10 this person read the title then ran to HN to comment. Just to clarify: No, most people barely know how to install software and definitely have problems installing software like Python that refuses to add itself to the PATH.

You want MSYS2.

This was repeated many times, as if MSYS2 was a magic solution to the problem of building software on Windows. Now, I remember actually testing MSYS2, Cygwin, various "gnu bash in windows" attempts, and a host of other solutions. They all had significant flaws in usability, Windows integration, and installation so I avoided them.

However, I hadn't tried MSYS2 in about a year (based on the time stamps on the files I have here), so maybe I should re-evaluate it. Also, this could be another essay where I go through my thought process when I evaluate something to solve a particular problem.

Therefore I present to you...

Why MSYS2 Sucks

First, we need to establish a few criteria for evaluation:

1. A solution to my problem has to be one that doesn't require me to help different people with different problems. What this means is--even if there is a solution to some problem--if I have to help someone apply that solution randomly based on some arbitrary event, then it's not a real solution. It's a hack to work around a flaw. This will come up when we talk about pacman and GPG so keep that in mind.
2. A solution needs to be something that my target user base can use without needing additional help from me. They can be expected to follow instructions, copy paste commands, and not know exactly what they're doing, but if I have to help 20% of them get past some thing then it's not a viable solution.
3. The solution has to be simpler when compared to my current solution of 2 PowerShell Scripts. This isn't just in the install process, but in how it's used after. We'll also define "simplicity" by what the user needs to understand to do some basic tasks I'll have them do.
4. And Finally, the solution has to have good performance because my target audience usually doesn't have amazing computers.

My Target Users

To follow along with this discussion it's important to know the kind of students I try to teach. I think this is the big disconnect because many of the comments above are probably written by that kind of programmer who myopically believes the entire world is exactly like them. They learned to code when they were 12 on a really nice computer so obviously everyone else totally knows how to run Debian Pathetic Potato 18.3.4.17-a in a Nix container inside a Docker in a Hypervisor VM controlled by Qubes for "securitay."

My target user is someone who hasn't written code, but is computer literate enough to use the internet, install software, and use basic software you might use at work. To define this further here's a list of what I imagine they can do:

1. They can access the internet, download software, and install it.
2. They have enough basic English to read my instructions, which also helps with programming since most programming languages use English.
3. They know how to find files on their computer, open them, and use them in the right application, but they usually don't understand the concept of a "path", that directories are in a "tree", or how a path is written out.
4. They have absolutely zero knowledge of programming at all, but they can use programmer tools if they're told how to use them. For example, they may not understand what print("Hello World") is doing, but they can type it into a ex1.py file, go to Terminal, and type python ex1.py to run it.
5. However, they will frequently make mistakes in #4 that a programmer would never make. They'll do things like type python to then type python ex01.py inside the Python REPL and wonder why they get weird errors. They'll create a file and save it, but have no idea how to get to it in Terminal.
6. Most importantly, they typically find constantly fixing their computer unproductive and tedious. Some programmers love nothing more than to spend 30% of their life massaging a Nix configuration controlled by Haskell in a special MUSL only Docker image, but normal people hate this kind of "Yak Shaving."

Any expectations beyond this are probably not going to work. If you think the above person can install and use Docker you're sadly mistaken. I'm a platinum star Linux user who started using Linux after buying a box of 72 floppy disks from Ygraddisil Linux in 1993 and I can't figure out Docker half the time. If you think my ideal user can figure out Docker you are both extremely delusional and completely out of touch with the rest of the world.

The PATH Test

To add a bit more understanding of my ideal user we can look at how they understand where files are in the computer. The concept of a path is completely foreign to them. To them files live "in the computer" and they have icons attached to them with names of locations. That means, they save files "in the Documents" or "on the Desktop." They also frequently don't understand how one Directory can be inside another Directory, but if they do understand that much they do not know how to map the graphical view of their files to the textual views of paths in Terminal. What makes this even worse is how Windows (and macOS) flat refuse to show users their full home directory. Microsoft wants the Explorer window to only show "Microsoft Approved" starting paths like Photos and Documents and getting it to show the user's actual root home is difficult.

Which means, if a user does know how to save their ex01.py file in C:\Users\jenny\lcthw\ they only know how to get to this file with Explorer and clicking their mouse. Most users however won't be able to even get at their C:\Users\jenny directory with Explorer since it's not immediately available, and they also wouldn't know that this is the text of their path because Explorer changes it to be Users > jenny for...reasons. Once the users does get to their file with the mouse, they then have the issue of getting that file into their Terminal. Unlike you and me, they can't just remember it and then type it out, so they need to use other techniques. I usually tell them to drag it into the Terminal which types it out, or to use start to open things from inside Terminal.

This means, if your proposed solution requires a user to understand that their files are in /c/User/jenny/Documents/Nix-flakes/Alpine/18.4 but only while in MSYS2 then you've already overloaded their understanding by 4 levels of indirection.

VMs Fail Miserably

Immediately we can exclude all the people who say to use any VM technology on each of the points:

1. On Windows many VMs have huge usability issues. Everything from BIOS changes needed to enable hypervisor settings to just having to configure networking and firewalls for simple internet operations. WSL2 helps, but even it has problems requiring fairly complex Network configuration just to access servers.
2. As mentioned above, something as simple as Networking would require my involvement most of the time. I'd have to help them understand Docker commands, or Hypervisor settings. I'd have to help them resolve the weird continuous disconnects of the VM viewer in the Hypervisor. I'd have to help them "get at their files" inside Docker, which is something I have to look up all the time. Then there's the problem of all these solutions being based on Linux which requires so much touching and maintenance that there's no way a user could work without issues.
3. VMs are also not simpler than my 2 scripts. My scripts run, things are installed, and people then use their computer as it is. No extra Linux education. No translating between Linux and Windows paths. No explanations about how a VM works, or why they can't get their files out of it. No explanations about why their copy-paste doesn't work. All their existing tools and knowledge work, I'm just adding the necessary programming tools to learn only programming.
4. VMs also never perform as well as the main computer. You may say, "But But you can change this setting or..." and I'll refer you the fact that most people I teach have computers that can't run full large VMs.

Alright, we've eliminated VMs, and I'll make one more bold statement that is sure to piss you off:

Any open source project distributing their code in a form that only works inside Docker is flawed. You're demonstrating that you don't even know how your own software works and that tells me your software is probably low quality.

Testing MSYS2

To test MSYS2 I removed my old install and reinstalled the very latest I could find. Immediately I ran into the following problems:

1. The installation takes forever because it's basically building an entire Linux system from scratch.
2. It uses pacman from ArchLinux, which is easily the worst package manager ever invented. Quick, how do you search for a package that you've installed? Oh? What's that, did you just have to google for one of the weird single letter options? I rest my case.
3. Because of pacman it uses GPG to ensure that packages only come from approved people, which is a good thing, but pacman is terrible at maintaining the keys. Right away this first install needed to update the key list, which isn't well documented, and only documented on ArchLinux or random blog posts. Think about this: To use MSYS2 a user would have to know that pacman is from ArchLinux, know that the GPG key errors require a keyring update, and know that they have to go find the docs to do this from the ArchLinux website.
4. After you get through this hurdle you then have to install the right software, and MSYS2 makes the "genius" decision of letting me pick which binary I want to install for every single install. Do you need to install fmpeg? Better spend an hour sifting through clang-amd64-ucrt-mingw32-ffmpeg vs. gcc-x86_64-w32-gnu-ffmpeg and tons of packages.
5. The paths you have to use to get at your files use a special mount point at /c/ which means there's two "sides" to the system now, and that also means that every user is now forced to learn both Linux and Windows on top of learning about programming. This is far too much for my intended users.

The GPG Keyring Problem

Remember that an important criteria I have is I shouldn't have to help different people with a problem at random. If everyone runs into a problem on the first install I may still use it because I can just tell everyone to fix it. If a problem only hits 20% of people for no reason, or happens randomly because of some external event then I can't really help them consistently. I'd have to create a whole guide of if-else conditions for each possible problem they'll run into.

The GPG Keyring problem in ArchLinux is exactly this kind of "random problem that hits some people" I don't want to solve. What is this problem? Randomly, when someone is added or removed to the package maintainers list, pacman will report this error:

error: clang64: signature from "X X" (MSYS2 development key) <email@email.com>`

Or, you'll get this error on a random update:

error: clangarm64: key "ADFASDFWERASADASDFASDFSADF" is unknown
:: Import PGP key ADFASDFWERASADASDFASDFSADF? [Y/n]

This is a horrible error message. It says absolutely nothing about the cause, why it happened, or how to fix it. What's the fix? Oh, that depends on what year you find your Google result in.

1. Maybe it's sudo find /var/lib/pacman/local/ -type f -name "desc" -exec sed -i '/^%INSTALLED_DB%$/,+2d' {} \;
2. Maybe the sacred rite is sudo pacman-key --populate archlinux
3. Maybe the magic incantation is sudo pacman-key --refresh-keys

These are just some of the solutions to this problem that should be totally automated by pacman the second it happens. In fact, I couldn't even find the solution I eventually used, that's how complicated it is. This problem is also random, since once day someone will add or remove someone and then I'll get people randomly coming in asking for help. To solve this, I'll add some "if you see this error" help in the install, and then another, and another, and another and so on.

Or, they run my 2 PowerShell scripts and just get back to using their computer as it is.

Evaluating MSYS2

We now come to the final evaluation of MSYS2 based on my criteria:

1. Random Issues needing my help? FAIL, and not just because of the keyring issue. I'll have to help them handle upgrades, which pacman is terrible at, or if pacman forces an upgrade that causes an exercise to fail for them on a random day. If you don't think these things happen, you haven't use pacman for long enough.
2. Can use it without help from me? FAIL, even if we get rid of the random events I'll still have to help with all kinds of random tasks. Getting their files out of MSYS2, or accessing services they start, or the difference between PowerShell and Windows, or why they can't just save their files in MSYS2 directly, and on and on.
3. Is simpler than 2 PowerShell scripts. No way MSYS2 is simpler than what I have. First, my scripts install things in the same way that Windows supports, so they can uninstall it using the usual Add or Remove Programs system. It even upgrades anything that needs to be upgraded in the list, so it shouldn't double install. It's also a lot less software that gets installed compared to the entire Linux system that MSYS2 installs. Finally, using the software I install only requires knowing Windows. Using MSYS2 requires using ArchLinux, easily one of the hardest to use Linux distros there is.
4. Good Performance I actually don't know if the MSYS2 binaries are slow, but I'm guessing they're at least as fast as native compiled binaries since it's not in a VM.

There you go, MSYS2 is a failure for my target users, and anyone who suggested MSYS2 needs to examine their concept of other people. If you're the kind of person who thinks MSYS2 is easy to use, then you are full on delusional. Even for a professional MSYS2 is hard to use, and doesn't provide any advantages over WSL, WSL2, or just the simple install I created.

Evaluating my 2 PowerShell Scripts

To be fair, let us evaluate my own solution using my own criteria:

1. Random Issues needing my help? The only issues I imagine needing to deal with will be from Anaconda or Python doing something weird because someone needs more money. Other things are easily dealt with by updating the installer scripts and having people re-run them. Also, any software that gives me trouble can be quickly ejected in favor of another solution.
2. Can use it without help from me? So far this is very true. People are using it, and saying it was easy and uneventful. I'll need more testing to confirm with a more varied install base, but so far it's a win.
3. Is simpler than other solutions. I've tried everything you can imagine, and honestly just being able to automate the install of a list of software is a big win. Other solutions so far can't really compare.
4. Good Performance As I said, this should be just as performant as any other software you install, since it's not running in a VM.

Now You Know

Consider this a challenge. I'm actually always open to making these installs a smooth as possible for people, and I want everyone to be able to get at programmer tools without going through multiple corporations. If you've got a solution that beats my 2 PowerShell scripts and works for my target users then bring it. I'm down. I want it. I need something better because currently getting a normal human up and running on Windows is a slog. I've got something that's working but I am not imagining it's the most ideal solution.

But if your answer is some bullshit like, "You want MSYS2 bro!" Followed by your best gangster pose then you can politely go

More from Learn Code the Hard Way