I'm trying to understand if I'm confused or is cargo doing something that it shouldn't.
I have a dependency that is not yet public, but it will be in the future, so we are using a github personal token temporarily.
[dependencies]
not-yet-public = { git = "https://x-access-token:github_pat_...@github.com/us/notyetpublic", rev = "1234" }
That works.
However when used in inner-dependencies, we would rather have the source to be without and auth part and force the auth via [patch] in downstream crates.
So downstream crates can do:
[dependencies]
not-yet-public = { git = "https://github.com/us/notyetpublic" }
[patch."https://github.com/us/notyetpublic"]
not-yet-public = { git = "https://x-access-token:github_pat_...@github.com/us/notyetpublic", rev = "1234" }
each, and use a different rev = when they have different exact pinning requirements and use the same https://github.com/us/notyetpublic without repeating this unfortunate github token everywhere (instead of just on [patch] section).
I think this should work, and is consistent how we sometimes temporary force public things to be replaced with temporary internal forks, etc.
Unfortunately when doing cargo build and cargo update, cargo insists on trying to do git clone https://github.com/us/notyetpublic which doesn't work (not public) and fail the whole command. Which is kind of odd, because https://github.com/us/notyetpublic is completely overridden and should no longer be needed.
Honestly, I find usage of [patch] confusing in complex DAG with many forked deps uses cases I have and not well described in public documentation (at least for non-trivial scenarios), so I mostly arrived here via lots of trial and error. I appreciate any pointers and explanations.