3 ms·

> having a mechanism like npm or pip or whatever to automatically handle that is probably easier Re-running `cargo install <crate>` will do that. Or install `c

> having a mechanism like npm or pip or whatever to automatically handle that is probably easier Re-running `cargo install <crate>` will do that. Or install `cargo-update`, then you can bulk update everything. And it works hella better than using pip in a global python install (you really want pipx/uvx if you're installing python utilities globally). IIRC you can install Go stuff with `go install`, dunno if you can update via that tho.

StochasticLi 1y ago
This whole thread is a great example of the developer vs. user convenience trade-off. A single, pre-compiled binary is convenient for the user's first install only.
- masklinn 1y ago
  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.
- MobiusHorizons 1y ago
  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
  - wiseowise 1y ago
    No, it doesn’t. At work everything is locked down and you either need to have separate mechanism to deliver updates or use pip.
    - berkes 1y ago
      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)
- JimDabell 1y ago
  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.
  - wiseowise 1y ago
    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.
    - JimDabell 1y ago
      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.
      - wiseowise 1y ago
        Sure it does. When you download it manually you become that package manager.
- berkes 1y ago
  > 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.
  - skydhash 1y ago
    > 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,...)
re-thc 1y ago
> Re-running `cargo install <crate>` will do that. Or install `cargo-update`, then you can bulk update everything. How many developers have npm installed vs cargo? Many won't even know what cargo is.
- riskable 1y ago
  Everyone in the cult knows what cargo is.
berkes 1y ago
Not even "cargo install" is needed. Just `wget -O ~/.local/bin/gemini-cli https://ci.example.com/assets/latest/gemini-cli https://ci.example.com/assets/latest/gemini-cli` (Or the CURL version thereof) It can pick the file off github, some CI's assets, a package repo, a simple FTP server, an HTTP fileserver, over SSH, from a local cache, etc. It's so simple that one doesn't need a package manager. So there commonly is no package manager. Yet in this tread people are complaining that "a single binary" is hard to manage/update/install because there's no package manager to do that with. It's not there, because the manage/update/install is so simple, that you don't need a package manager!
- owebmaster 1y ago
  > is so simple, that you don't need a package manager! You might not know the reason ppl use package managers. Installing this "simple" way make it quite difficult to update and remove compared to using package managers. And although they are also "simple", it's quite a mess to manage packages manually in place of using such battle-tested systems
  - berkes 1y ago
    > You might not know the reason ppl use package managers. People use package managers for the following: - to manage dependencies - to update stuff to a specific version or the latest version - to downgrade stuff - to install stuff - to remove stuff any of these, except for the dependency management, are a single command, or easy to do manually, with a single compiled binary. They are so simple that they can easily be built into the tool. Or handled by your OSs package manager. Or with a "shell script" that the vendor can provide (instead of, or next to, the precompiled binary. I did not say manually, you infer that. But I never meant that. The contrary: because it's so simple, automating that, or have your distro, OS or package manager do this for you, is trivial. As opposed to that awful "curl example.com/install.sh | sudo tee -" or those horrible built-in updaters (that always start nagging when I open the app - the one moment that I don't want to be bothered by updates because I need the app now) The only reason one would then need a package manager is to manage dependencies. But a precompiled binary like Go's or Rusts typically are statically compiled so they have no (or at most one) dependency. Imagine the ease of a single ".targz" or so that includes the correct python version, all pips, all ENV vars, config files, and is executable. If you distribute that - what do you still need pip for? If you distribute that, how simple would turning it into a .deb, snap, dmg, flatpack, appimg, brew package, etc be? (Answer: a lot easier than doing this for the "directory of .py files. A LOT)

StochasticLi 1y ago

This whole thread is a great example of the developer vs. user convenience trade-off. A single, pre-compiled binary is convenient for the user's first install only.

masklinn 1y ago
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.
MobiusHorizons 1y ago
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
- wiseowise 1y ago
  No, it doesn’t. At work everything is locked down and you either need to have separate mechanism to deliver updates or use pip.
  - berkes 1y ago
    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)
JimDabell 1y ago
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.
- wiseowise 1y ago
  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.
  - JimDabell 1y ago
    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.
    - wiseowise 1y ago
      Sure it does. When you download it manually you become that package manager.
berkes 1y ago
> 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.
- skydhash 1y ago
  > 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,...)

re-thc 1y ago

> Re-running `cargo install <crate>` will do that. Or install `cargo-update`, then you can bulk update everything. How many developers have npm installed vs cargo? Many won't even know what cargo is.

riskable 1y ago
Everyone in the cult knows what cargo is.

berkes 1y ago

Not even "cargo install" is needed. Just `wget -O ~/.local/bin/gemini-cli https://ci.example.com/assets/latest/gemini-cli https://ci.example.com/assets/latest/gemini-cli` (Or the CURL version thereof) It can pick the file off github, some CI's assets, a package repo, a simple FTP server, an HTTP fileserver, over SSH, from a local cache, etc. It's so simple that one doesn't need a package manager. So there commonly is no package manager. Yet in this tread people are complaining that "a single binary" is hard to manage/update/install because there's no package manager to do that with. It's not there, because the manage/update/install is so simple, that you don't need a package manager!

owebmaster 1y ago
> is so simple, that you don't need a package manager! You might not know the reason ppl use package managers. Installing this "simple" way make it quite difficult to update and remove compared to using package managers. And although they are also "simple", it's quite a mess to manage packages manually in place of using such battle-tested systems
- berkes 1y ago
  > You might not know the reason ppl use package managers. People use package managers for the following: - to manage dependencies - to update stuff to a specific version or the latest version - to downgrade stuff - to install stuff - to remove stuff any of these, except for the dependency management, are a single command, or easy to do manually, with a single compiled binary. They are so simple that they can easily be built into the tool. Or handled by your OSs package manager. Or with a "shell script" that the vendor can provide (instead of, or next to, the precompiled binary. I did not say manually, you infer that. But I never meant that. The contrary: because it's so simple, automating that, or have your distro, OS or package manager do this for you, is trivial. As opposed to that awful "curl example.com/install.sh | sudo tee -" or those horrible built-in updaters (that always start nagging when I open the app - the one moment that I don't want to be bothered by updates because I need the app now) The only reason one would then need a package manager is to manage dependencies. But a precompiled binary like Go's or Rusts typically are statically compiled so they have no (or at most one) dependency. Imagine the ease of a single ".targz" or so that includes the correct python version, all pips, all ENV vars, config files, and is executable. If you distribute that - what do you still need pip for? If you distribute that, how simple would turning it into a .deb, snap, dmg, flatpack, appimg, brew package, etc be? (Answer: a lot easier than doing this for the "directory of .py files. A LOT)