workspaces should treat source-replacement'd crates identically to crates.io ones

[froydnj]

Consider a source tree layout like structure like:

- <root>
  - vendored_crates/
    - project/
      - Cargo.toml # defines workspace
      - sublibrary/
      - ... # subdirectories
  - foo/
    - Cargo.toml # defines workspace
    - library/
      - Cargo.toml # has path dependency on ../../vendored_crates/project/sublibrary

Furthermore, vendored_crates/ is treated as a source-replacement path for crates.io.

It doesn't matter too much whether foo/Cargo.toml is in foo/ or the project root: if you attempt to build foo/library/, Cargo will complain that vendored_crates/project/sublibrary/ belongs to the vendored_crates/project/ workspace, and that's one workspace too many.

This behavior makes using vendored crates inconvenient, because you would have to strip out workspace-ness from various places when vendoring, which is undesirable and fiddly. Cargo should treat these source-replacement'd crates identically to the ones downloaded from crates.io.

[alexcrichton]

I agree, the intention of source replacement is to be totally transparent!

I'm curious, though, how come <root>/foo/library has a path dependency on <root>/vendored_crates/project/sublibrary? Presumably if project is in crates.io so is sublibrary?

[froydnj]

I'm curious, though, how come /foo/library has a path dependency on /vendored_crates/project/sublibrary? Presumably if project is in crates.io so is sublibrary?

The project/sublibrary in this case is actually servo/ports/geckolib/, where geckolib is part of servo and depends on parts of servo, but not the entirety of it. All of servo is vendored (or, really, imported; we don't actually vendor it from crates.io).

[froydnj]

So perhaps things do work fine and it's only our awkward directory structure that keeps this from working. =/

[alexcrichton]

Oh ok so in the example above project is just coincidentally in the vendor directory, it's not actually being used through source replacement?

If that's the case I wonder if this boils down to #3192? You basically want a way to say "no, really, geckolib is not in this workspace"

[froydnj]

Oh ok so in the example above project is just coincidentally in the vendor directory, it's not actually being used through source replacement?

That's correct.

If that's the case I wonder if this boils down to #3192? You basically want a way to say "no, really, geckolib is not in this workspace"

Probably! Seems all of our problems boil down to that bug. :)