[gpm]

I think you're fundamentally misunderstanding what is going on here, because your questions about "namespacing", "being shared between objects", and "building installing things" suggest your imagining a system that doesn't exist here. Cargo, unlike a system like pip, doesn't have global files*, it doesn't have libraries installed to the system, there is no* global state to corrupt.

The only "side effect" of running a `cargo install` command is that a binary is placed in `~/.cargo/bin`, which most rust programmers will have on their PATH. There are no side effects of running a normal cargo build, it won't update anything outside of the crate you are building (and in the crate you are building, it will only change Cargo.lock and the target directory). There isn't any scary action at a distance.

> What causes it to be updated?

Nothing, except a user manually running `cargo install --force imgcatr`. This is the main criticism of using `cargo install`, it's not a package manager, it's a shortcut to doing the C equivalent of `git clone project && cd project && ./configure --prefix=~/.cargo/bin && make && make install` (but for binaries only, no libraries).

* There is a local cache of checked out code, and the index of crates, which is generally updated every time you run a `cargo build` command that might need anything that isn't local. You can use this cache without touching the internet by specifying `--offline`, at which point the contents of the cache matters. The only reason to do this is if you don't have internet. I'm also ignoring nonsense that people can put in `build.rs` files, but pretty much no one does. Rust will also look for certain global dependencies on your system (namely C style libraries), but it doesn't have any support for putting new ones there.

[wokwokwok]

> command is that a binary is placed in `~/.cargo/bin`, which most rust programmers will have on their PATH

That is a global effect.

> Nothing, except a user manually running `cargo install --force imgcatr`.

I’m absolutely certain build.rs can also do this; you can choose to ignore that if you want.

I hope ignoring it makes it not a thing we have to ever worry about. I guess.

I get it, it’s convenient; but I think people are fooling themselves if they think having a binary on their path is no big deal, or that manually calling “cargo install” is the only way this can happen.

FWIW, there is a precedent with serde shipping a binary (https://github.com/serde-rs/serde/releases/tag/v1.0.184 related discussion etc. which kind of shows this is not an idle concern)… mmm… oh well, whatever I guess.

[gpm]

> That is a global effect.

Yes, I agree, that's why I said it is the only one. Moreover the sole purpose of cargo install is to cause that side effect (otherwise you use cargo build, which builds the binaries but doesn't copy them to a shared directory).

> I’m absolutely certain build.rs can also do this

build.rs is running arbitrary code, it can do anything, that's part of what I disclaimed in my asterix. In practice it doesn't do anything. Every packaging system has an escape hatch like this.

Serde shipping a binary was someone embedding a chunk of opaque bytes in their "source code", it's completely unrelated to this discussion and has no effect on what `cargo install` does.