override "current package believes it's in a workspace"

[durka]

If you create a crate inside another one, sometimes you get the above quoted error when trying to build it.

As far as I can tell, there's no solution. You can never build the crate because it's not really in the workspace, yet you can't build it separately either. The only recourse is to move the whole thing to another directory.

I propose a new flag, called something like --no-workspace or --believe-nothing--reality-is-fake--just-build-here, that would ignore the surrounding workspace and build the crate as it would have done before workspaces were invented. Does this make sense?

[sfackler]

It sounds like workspace.exclude? https://doc.rust-lang.org/cargo/reference/manifest.html#the-workspace-section

[durka]

I guess that's a workaround, but modifying the outer crate (the one that's interfering with my ability to build the one I just created) is not an ideal solution. The error message is non-intuitive (the crate "believes"? based on what evidence? since when do TOML files have beliefs??) and hampers quick experimentation.

[gnzlbg]

I ran into this here, #5421 which arnavion suggested on IRC is a duplicate of this one. I worked around the issue by adding a:

[workspace]
members = []

to the crate in question.

[matklad]

Yeah, the current solutions to this are

• add exclude to the parent crate

• add

  [workspace]
  

  to the current crate (note that members = []) is not really required.

I wonder if cargo new should add an empty workspace key by default?

[gnzlbg]

The error message should at least mention the current solutions, I did not know about exclude, it would have been an option for me as well.

[durka]

This still gets me every time. Would a PR to change the behavior of cargo new as @matklad suggested be accepted?

[dwijnand]

I think if it's conditional on being nested in another crate, then yes, allowing regular cargo new to remain unaffected.