> A single, pre-compiled binary is convenient for the user's first install only.

Its not.

Its convenient for CIs, for deployment, for packaging, for running multiple versions. It's extremely simple to update (just replace the binary with another one).

Now, e.g. "just replacing one file with another" may not have convenience commands like "npm update". But its not hard.

My point is that a pre-compiled binary is extremely more convenient for *everyone involved in the delivery pipeline* including the end-user. Especially for delivering updates.

As someone who's packaged Javascript(node), Ruby, Go and rust tools in .debs, snap, rpms: packaging against a dynamic runtime (node, ruby, rvm etc) is a giant PIAS that will break on a significant amount of users' machines, and will probably break on everyones machine at some point. Whereas packaging that binary is as simple as it can get: most such packages need only one dependency that everyone and his dog already has: libc.

> My point is that a pre-compiled binary is extremely more convenient for everyone involved in the delivery pipeline* including the end-user. Especially for delivering updates.*

The easiest is running "sudo apt update && sudo apt upgrade" and have my whole system updated. Instead of writing some script to get it done from some github's releases page and hoping that it's not hijacked.

Having a sensible project is what make it easy down the line (including not depending on gnu libc if not needed as some people uses musl). And I believe it's easy to setup a repository if your code is proprietary (Just need to support the most likely distribution, like ubuntu, fedora, suse's tumbleweed,...)

I don’t think that’s true. For instance, uv is a single, pre-compiled binary, and I can just run `uv self update` to update it to the latest version.

I literally wouldn’t use uv if it weren’t available via pip.

Reasoning: it’s a Python tool, therefore it shouldn’t require anything (any 3rd party package manager) beyond Python.

It’s a standalone binary. It doesn’t require anything at all. It’s literally just one file you can put anywhere you like. It doesn’t need a third-party package manager.

Sure it does. When you download it manually you become that package manager.

Unless you build self-updating in, which Google certainly has experience in, in part to avoid clients lagging behind. Because aside from being a hindrance (refusing to start and telling the client to update) there's no way you can actually force them to run an upgrade command.

How so? Doesn’t it also make updates pretty easy? Have the precompiled binary know how to download the new version. Sure there are considerations for backing up the old version, but it’s not much work, and frees you up from being tied to one specific ecosystem

No, it doesn’t. At work everything is locked down and you either need to have separate mechanism to deliver updates or use pip.

That's not an argument against the difficulty of "updating a binary file" vs "updating via pip", it's merely addressing what your work deems important and possible.

(Aside from the fact that allowing "use pip" completely defeats the purpose of any other of these mechanisms, so it's a poster-child example of security-theater)