I built a student project in Python to teach them some basic cryptography stuff. The code is all in Python 3, but requires some libraries with native components (notably, GMP for bignum support).

I tested it. I even made sure it worked on my M1 Mac laptop.

Handed out Friday.

Oh wow. Student machines are all over the map in the errors they're experiencing. This is a tech support nightmare for me. It's got a straightforward Makefile that runs all the right pipenv commands. And it breaks in really subtle ways on different student machines.

For contrast, I've previously handed out assignments in Java, using the Gradle build system (same as Android apps use). You pretty much just install a JDK and you're good to go. Everything kinda just works.

I can see why people just give up and use virtual machines or Docker. There's just too much variation out there in the Python universe and no way of knowing whether you'll have it all done right.

Sigh.

The big issue is that there's no such thing as "Python". There's "Python1", "Python2", and "Python3". Three different, incompatible languages that happen to use the same spelling for the name. And then same idea with add-ons.

Right, but when you install something from a Pipfile / Pipfile.lock, then sometimes it goes on to try to compile a C library, while other times it doesn't. So it's not just that there are multiple Pythons. It's that there's so much native C code floating around that it really hampers portability.

Example: numpy is widely used in the data science world for efficiently computing on tabular data. Of course, all the underlying crunching happens in C code. As of a year ago, getting it to run on an M1 Mac was a nightmare. Oh, don't use Homebrew. Use Conda. Or follow these weird steps. I haven't tried again recently, but uggh. Depending on *how* you install Python, you may have different challenges getting all the libraries you need.

For contrast, in Java, there's relatively little native code that comes along with most libraries. They're mostly just pure Java. I installed a JVM on my M1 Mac and all my old stuff just worked. No tweaking. No corner cases. It all just worked the first time.

VS Code with a devcontainer.json file?

See https://code.visualstudio.com/docs/remote/create-dev-container

I've not tried it (yet), but I have used VS Code Remote with WSL, Docker and SSH. I've just not tried the devcontainer.json thing.

We've got an internal tool that uses Python; I run it using nix-shell. Even then it's fragile.

I had a consulting gig a few years ago where they used Nix for a cross-compilation environment. When you need it, you really need it, but wow, the first time you install Nix and it has to download and install the entire universe? I can see students saying "oh, never mind, I'll just run a local Python installation."

I'm increasingly seeing the wisdom of just giving them a VM with a pre-installed Linux image and being done with it. So what if it's utterly antiquated and insecure in a few years? It will still get the assignment done.

(For this specific student assignment, for fun and giggles, I also wrote the assignment in Kotlin. The code is a lot more elegant than the Python code. Java's BigInteger is maybe half the speed of the GMP's mpz type, but that's irrelevant for the students. Sadly, I surveyed the students at the start of the semester, and only two out of 100 had any Kotlin experience, so I decided not to inflict that on them. I'm pondering how to back-port it from Kotlin to Java without making a mess out of it.)

This devcontainer business seems interesting. GitHub Classroom (the thing we use to clone starter repositories for the students) knows how to set things up to launch VSCode in some sort of remote capacity. I should probably invest the effort to understand how to put all the pieces together.