patch table fails to rewrite dep to local path if it’s published in Cargo registry

[sanmai-NL]

cargo 0.25.0-nightly (a88fbace4 2017-12-29)

Patching crates.io dependencies to use a local path does not work from a virtual manifest.

E.g. virtual manifest (./Cargo.toml):

[patch.crates-io]
sitemap = { path = "./in-house-sitemap/" }

Workspace member package manifest (./package/Cargo.toml):

[dependencies]
sitemap = "*"

This will pull in the sitemap crate from crates.io, unlike similarly rewritten dependencies where no crate with the same name is published in the Cargo registry.

[alexcrichton]

Have you tried updating Cargo.lock? If not, can you provide an example to work with?

[sanmai-NL]

You mean running cargo update? Yes. I’ll try to make a complete example if I have more time.

[alexcrichton]

Hm so some dependencies are being rewritten when others aren't? Are you sure that package/Cargo.toml is in the same workspace as the root one perhaps?

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[sanmai-NL]

This issue is still relevant. Unclear whether any issue blocks this or what can be done other than fixing Cargo.

[alexcrichton]

@stjepang it's currently intended behavior that [patch] is read at the workspace level (not per-crate level). It's a bug, though, that we don't warn about [patch] in sub-crates.

@sanmai-NL were you able to make an example for this? It's difficult to fix as it's not clear to me how to reproduce and there's some unanswered questions above.

[sanmai-NL]

@alexcrichton: I’m sorry, I haven’t got around to that. I thought the OP should be enough but so far it isn’t. I’ll make an example ASAP.

[theduke]

I have encountered this issue as well.
Issue was fixed by deleting Cargo.lock.

I tried to reproduce it for about half an hour, but it couldn't manage to get a simple workspace to run into the same issue.

The only observation I can offer: the error I received was related to a stale version of a dependency that was not required by any of the crates anymore.

[epage]

As this has been sitting open for 5 years without reproduction steps, I'm closing it. If someone can figure it how to reproduce this, let us know!

[sanmai-NL]

As this has been sitting open for 5 years without reproduction steps, I'm closing it. If someone can figure it how to reproduce this, let us know!

If anything, the repro steps are in the opening post.

[epage]

I was going off of alex's comment

It's difficult to fix as it's not clear to me how to reproduce and there's some #4936 (comment) above.

That made me think something was left out of the reproduction steps.

In general, I feel the reproduction steps are inadequate. I might see an issue but it will be unclear if its the issue you are having. A repo would be a big help.

[weihanglo]

It might be something similar to #12464.
But yup a clearer step to reproduce would be really helpful for investigation.