Repository navigation
package metadata defined in a workspace not utilized聽#864
Description
Activity
I think I know what the problem is, and it's going to be tricky to solve. Let me try to explain it.
- Cargo Lambda just invokes
cargo buildwith the options that it collects from configuration. - Because you're running
cargo lambda buildin the workspace, it's going to end up runningcargo buildin the workspace, building all the packages in it. - Because the build applies to all workspace, there is no way to tell Cargo "read this metadata when you build this subpackage", unless you specify the subpackage to build.
I'm not sure if there is a way to fix that, I'm open to suggestions.
The workaround is to specify the package name you're building with
cargo lambda build member.- Cargo Lambda just invokes
@rtyler this configuration in the workspace should work to enable a feature in a subpackage without specifying the package name in the build command:
Cargo.toml in workspace:
[workspace.metadata.lambda.build] output_format = "zip" features = ["member/lol"]Cargo.toml in subpackage:
[features] lol = []Reacted by honestlysam
I have a feeling this is a bug but I'm still not certain where it might live 馃悰 When using
cargo-lambdainside of a workspace project, the setting of project-specific metadata inCargo.tomldoesn't seem to apply.For example, if I use the following in a
member/Cargo.tomlThis will not be read by
cargo lambda build.Workspace level configuration in
./Cargo.tomldoes work, but of coursefeaturescannot be defined in the workspace 馃槮