`cargo install` should respect `[patch]` from user config

[loynoir]

Problem

I want to install XXX with a patch.

/home/user/.cargo/config.toml

[patch.crates-io]
XXX = { path = '/home/user/git-cloned-XXX-with-patch' }

cargo install XXX is still installing the original version.

Steps

No response

Possible Solution(s)

cargo install should respect patch

Notes

No response

Version

cargo 1.73.0

[weihanglo]

Cargo generally starts a config discovery from the current working directory.

However, it is not the case for cargo install. cargo install as a user-level not project-level command (at least for now), it reload config file from you CARGO_HOME.

It makes sense to me for cargo install to respect [patch] from user config, as it already respects build.rustflags config. ~/.cargo/config.toml is often seen as a config for the user. Yet I didn't look closer enough to identify why it doesn't work.

[ehuss]

The cargo team discussed this, and we didn't have any specific reasons to not support that.

There was some confusion as to why this isn't working, but I just looked and understood the reason is that patch only works on dependencies during resolution. cargo install fetching the top-level thing (the thing you are installing) does not use the resolver for anything, and thus patch is completely out of the equation. There would need to be special-case code for it to look at the patch table and to try to resolve it. I'm not sure how complex or difficult that would be (the mechanisms used here are quite different). If it is unusually difficult, then we may not want to support that.

I'm marking this accepted conditional on how complex the solution might be.

[epage]

Oh, I had missed that this was for patching what you install and not what it depends on.

@loynoir could you help me understand the use case for this? I would have assumed that if you want to install something from somewhere else, you would just specify that to cargo install but that you asked for this means I am missing something.

[loynoir]

According to my memory, I was installing cli tool.

And that cli tool need to download asset using maybe-non-reqwest builder with hard code timeout, which leads to cli failure within my side.

So, I git clone repo, and patch that hard code timeout number.

[loynoir]

The original real world problem is patch hard-code-timeout-cli.

So, the best solution is not supporting path to patched large dir, but supporting patch-dir/XXX.patch pattern.

I currently don't have good example of famous nodejs repo using repo/patches/XXX.patch pattern supported by pnpm and yarn.

https://github.com/configu/configu/blob/main/patches/giget.patch