workspace_path can now act as a Bazel label within a Bazel workspace

[UebelAndre]

This change makes it so that the Cargo.toml file can live within the recommended location and cargo-raze will output content into a Bazel workspace in a way that better matches the expectations set by Bazel's naming conventions

├── BUILD
├── Cargo.lock
│
├── Cargo.toml  <- HERE
│
├── README.md
├── cargo
│   │
│   ├-   <- INSTEAD OF HERE
│   │
│   └── libloading_global_static.BUILD
└── src
    └── main.rs

This makes it easier to transition Rust projects to start using Bazel since users no longer have to move their Cargo.toml files and the use of workspace_path (which looks like a Label) makes more sense. Getting started with Bazel/cargo-raze should now only require users to add the [raze] section to their existing Cargo.toml file and run cargo raze (assuming they're using the remote genmode, but otherwise could vendor the packages and do the same thing).

The smoke-tests show the up to date examples but I wasn't sure if I should update the actual examples with the generated results of the smoke-tests. Anyway, this is my first ever PR in Rust and am looking forward to the feedback 😄

[UebelAndre]

@damienmg are you able to take a look at this or ping someone who can?

[yesudeep]

I've been using symlinks for this and put the cargo directory in //third_party/cargo.
This should help!

[UebelAndre]

Yeah, I used symlinks to put my Cargo.toml file in the correct place such that rust-analyzer would work. But I feel this is a worth while change. I think cargo-raze shouldn't force users to move their Cargo.toml files. Especially since debugger support for rust through Bazel is kinda spotty. It's nice to be able to lean on the current rust tooling/ecosystem until the Bazel tooling matures enough to completely replace it.

[dfreese]

@UebelAndre sorry for the delay, and thanks for the PR. I've gone through and reviewed the code based on the current implementation.

I know that some of my teammates have also symlinked the Cargo.toml and Cargo.lock of our project into the workspace root to be more compatible with RLS, so I'm definitely open to exploring this sort of change, however, would there be a way to do it in a way that wouldn't be a breaking change? One thought would be a flag to opt-in to this behavior.

[damienmg]

@damienmg are you able to take a look at this or ping someone who can?

Sorry for the delay I tend to not look at Github outside of working hours (especially I am not even allowed to work on sundays in my country).

[UebelAndre]

@UebelAndre sorry for the delay, and thanks for the PR. I've gone through and reviewed the code based on the current implementation.

@dfreese Hey, no problem at all :D

I know that some of my teammates have also symlinked the Cargo.toml and Cargo.lock of our project into the workspace root to be more compatible with RLS, so I'm definitely open to exploring this sort of change, however, would there be a way to do it in a way that wouldn't be a breaking change? One thought would be a flag to opt-in to this behavior.

I added an incompatible_relative_workspace_path (names are hard 😜 ) flag to allow for "opt-in" behavior. I feel strongly that this should at some point become the default behavior which is why I updated the smoke-tests and went with an incompatible flag.

[yesudeep]

I know that some of my teammates have also symlinked the Cargo.toml and Cargo.lock of our project into the workspace root to be more compatible with RLS

This breaks on Windows, which is why something that doesn't depend on symlinks may be a better idea.

[UebelAndre]

@dfreese Hey, got time this week to do another review? 😅

[UebelAndre]

Maybe @smklein or @acmcarther might have some time if @dfreese is not available? 😅

[UebelAndre]

Hey @damienmg, don't mean to be a bother but do you know how I can get some review support for this PR? 😅

[UebelAndre]

@dfreese Hey, I noticed you made changes to this repo recently. Do you think you could take a look at my PR as well? Or if not just let me know when you might have time?

[damienmg]

Hi @UebelAndre,

Unfortunately this is not a good time for me, but I'll try to take a look this week. Let see also if @mfarrugi have some bandwidth

[damienmg]

(sorry for the misclick)

[mfarrugi]

This looks fine to me, and addresses the earlier comments. I don't think I've reviewed anything else for this codebase, though.

[damienmg]

I also did a pass and see no issue with this code, I consider this one as good to go then seeing how many times it has been reviewed.

Thanks a lot for your patience!