Yep, and you'll have pip3-gil and pip3-nogil binaries because each permutation of python has separate and incompatible site-packages folders and libraries. It could get really ugly.

Lol the correct statement is it will get really ugly. Pretty much no question it will be a bigger mess than 2 to 3 transition. Here's hoping my subfield will move to a different language in the meanwhile because I don't want to deal with this shit again.

All your hopes of GIL free code ruined by a GIL requiring left pad dep buried deep in the dependency tree.

Fortunately Python’s package management is so horrible left pad is not a problem.

Is the situation in rust, where the answer is apparently to vendor the world, much better? Don't many of the big rust libraries still depend on nightly, too?

The major difference with rust is that the core language has strong backwards compatibility guarantees, and the package manager supports installing multiple versions of transitive dependencies so packages can be updated incrementally.

Right. GP was complaint about having a gazillion versions of every dependency sitting around to satisfy various whims.

> Don't many of the big rust libraries still depend on nightly, too?

No, none of them do, or at least none that I’ve ever seen in 4 years of doing rust full-time.

Or it could motivate total abandonment of system-level Python installations in favor of per-app virtualenvs or whatever the new hotness is, and we'll finally achieve world peace.

I can see system level python installs being abandoned. They seem to be getting progressively harder to use over time. I don't see the replacement being virtual env, it'll be a different language ecosystem. Whichever one looks like it has remembered "easy to do simple things in" is a feature.

While Python has never been my primary coding language, I've used it extensively for building scripts and tools, but I've pretty much given up on it. The language is so elegant, but the installation of it (with 2~3 compatibility issues being just a small part of that) just became such a turnoff. It's been super frustrating having to search the Internet every time I need to install something Python-related, to then find all sorts of conflicting instructions, bleh. Virtualenv, venv, a different Pip in Ubuntu, and so on. Since there's a lot of references to Java in these discussions: there's "sadly" two ways to do it: Maven and Gradle. That's still one too many, but at least not a new flavor du jour every year, like seemingly with Python.

And I'm sure someone will drive by, now, and tell us we have to use xyz, "obviously". But if that's not "obviously" what I find in an Internet search, then the community has apparently not agreed on it consistently in a sustained way.

The new official Scala build tool / compiler front end (scala-cli) is amazing,

https://scala-cli.virtuslab.org/

The thing that really struck me after years of python is how it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings. It's so simple!

> it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings

The old-style nix-shell command in Nix can do this[1] for every language and package Nixpkgs supports, although it’s not that often used because it ties your shebangs to Nix. (An equivalent feature for the new CLI is a work in progress[2].)

[1] https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht...

[2] https://github.com/NixOS/nix/pull/5189

Just curious: what makes it "official"?

It's going to be rolled out as the new standard Scala repl and compiler (instead of the current scalac which is a bit weak on features.)

Having different build tools, that’s one thing. I can live with a somewhat wonky development environment to work on my code, as long as I can set it up once and it works after that. I would prefer elegance, just one is used and that’s it, but I don’t know of a language with a large user base that has that.

My point lies more in the install experiences for say, a command line tool written in said language. For Java I need one Java install on my system, it’s the most recent one. I install it and then all the old code just works, all my Java command line tools just work, I never have to watch homebrew install some stupid version of Java@11 when I have Java@13 installed like I do [email protected] when I know I already have [email protected]. All of this is BECAUSE people basically threw up their hands and distribute the core language at their version with their code and their chosen dependencies “installed” into it… so we’ve all got 15 bespoke versions of the same language kicking around on our hard drives. That is really stupid.

When I learned Python decades or so ago virtualenvs were standard practice. Who is using system level Python for anything non-trivial?

I use Debian's system Python 3.10 install for most of my stuff and it works really well for me. Some things I install via pip but the key libraries (e.g. PyTorch) from source.

Don't you ever have projects with conflicting requirements? How about running stuff on a new box or after a reinstall?

I wonder if our definition of "non-trivial" might differ if neither of these apply.

I think this is standard and I find it a total and complete waste of my hard drive space.