Add cargo build option to select which workspace to look for

[Berjou]

Describe the problem you are trying to solve

Currently working on a webapp with the following project structure:

mywebapp/
  |_ backend
    |_ Cargo.toml (defining a mywebapp = { version = "x.x.x", path =" .." } dependency)
  |_ frontend
    |_ Cargo.toml (defining a mywebapp = { version = "x.x.x", path = ".." } dependency)
  |_ src
    |_ root crate source code used by the backend and frontend workspaces
  |_ Cargo.toml (defining `backend` and `frontend` workspaces members)

Note that there is no direct dependency between the frontend and backend workspaces (but they both use common code defined in the root crate).

I can build this code without problem on my dev machine. However, problems appears when trying to setup a CI. Since the frontend and backend need different build dependencies, it make sense I think to use different docker images both using only the strictly required dependencies to build them. For exemple, there is my docker image used to build the backend part of the project:

FROM ekidd/rust-musl-builder AS backend-builder
COPY ./backend/ ./backend/
COPY ./src/ ./src/
COPY ./Cargo.toml .
RUN cargo build -p mywebapp-backend

But here, cargo complains that it cannot read frontend/Cargo.toml. Of course, there are multiple way to make this work, but none of them feels right:

• COPY the frontend directory as well, but that means giving access to files that should not be needed to my docker image.
• do not COPY directories and mount the root crate as a volume, but again give access to unnecessary files to my docker image.
• move the frontend and backend directories inside a new crates directory and defining workspaces member as crates/* using globing and COPY or mount only the needed crates inside my docker image. This seems to be the cleanest solution so far, but feels like a hacky way to tell cargo to look for the backend workspace and not for the frontend one.

Describe the solution you'd like

I think that a cargo build option allowing the dev to include/exclude/select which workspace to look for (maybe similar to the --package option) would be a cleaner and simpler way to handle this problem

[epage]

The challenge here is the workspace is a unit and removing items affects the unit, like the generation of Cargo.lock.

This seems like something that should be explored outside of cargo, much like cargo-chef is exploring improvements for layering (see #2644). I would recommend seeing if cargo-chef supports this use case or see if it can be added.