cargo: A dependency on `path = "."` should have a good error message
In a package foo a [dev-dependencies] foo = { path = "." } should be an error.
As there is no use case for it, and it does not do what most people expect.
There are not many people that will try this, and there are few configurations that don’t error already. So I don’t think we need to get too fancy with the comparison. A check for a path "." would be a big step foreword.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Comments: 16 (13 by maintainers)
@yerke let me start off by apologizing. You deserve a prompt and knowledgeable response from me. This response is certainly not prompt and not as thorough as I would like it to be. In the time since I posted this issue, all the context has gone out of my head. I am doing my best to reconstruct it now.
For
dependenciesandbuild-dependenciesapath="."already errors because it must create an infinite loop in the build order. However things are more complicated fordev-dependencies. There always exists an implicit dev-dependency from the binarys/tests on the lib. The question is whether thepath="."syntax unifies with that implicit edge or if it makes a new path package. From my reading (but I have not gone back to test) different versions of Cargo have been inconsistent on the behavior of this syntax over time. Some versions it errored as building 2 incompatible versions of the same library, or it built it twice, or it unified. Currently different aspects of cargo seem to have different opinions about what this means. (For example #9454, if you rename thepath="."dependency it gets ignored and not marked as duplicate.) Generally tracking down these bugs and figuring out what is the correct behaviour is not worth the effort. Hence this issue to just ban the syntax.On the other hand it happens to be that with
resolver="2"the bugs line up to work ok as a workaround for #2911. Until a better work around is found (CARGO_PRIMARY_PACKAGE) or a permanent fix is implemented (https://github.com/rust-lang/rfcs/pull/3020) one can argue that we should let it be.I will bring it up at the next Cargo Team meeting, and get back to you.
I did bring it up at last week’s Cargo meeting and then forgot to write the update here 🤦 , Sorry.
build.rs can set rust features, but it can not turn on optional dependencies. So this is also only a workaround.
We agreed that we do want to ban this syntax, eventually. Given that the most pressing bugs so far reported is #9454 (not very pressing) and that people are using it to work around #2911 we decided to not make it a hard error at this time. This decision can and will be re evaluated when better alternatives are available or we find more pressing bugs.
@yerke your PR is significantly more robust then the code I had in mind. Thank you for your contribution! When we ban this behavior, it will be based on your code. I am sorry I was slow and confusing in my communications, and that I left
E-help-wantedon something it turned out we were not ready to do.I don’t have a good suggestion, but how does this sound: “a project can not depend on itself as a path dependency”