ef5b8c6fed
We've been considering removing workspace-hack for a couple reasons: - Lukas ran into a situation where its build script seemed to be causing spurious rebuilds. This seems more likely to be a cargo bug than an issue with workspace-hack itself (given that it has an empty build script), but we don't necessarily want to take the time to hunt that down right now. - Marshall mentioned hakari interacts poorly with automated crate updates (in our case provided by rennovate) because you'd need to have `cargo hakari generate && cargo hakari manage-deps` after their changes and we prefer to not have actions that make commits. Currently removing workspace-hack causes our workspace to grow from ~1700 to ~2000 crates being built (depending on platform), which is mainly a problem when you're building the whole workspace or running tests across the the normal and remote binaries (which is where feature-unification nets us the most sharing). It doesn't impact incremental times noticeably when you're just iterating on `-p zed`, and we'll hopefully get these savings back in the future when rust-lang/cargo#14774 (which re-implements the functionality of hakari) is finished. Release Notes: - N/A
28 lines
573 B
TOML
28 lines
573 B
TOML
[package]
|
|
name = "bedrock"
|
|
version = "0.1.0"
|
|
edition.workspace = true
|
|
publish.workspace = true
|
|
license = "GPL-3.0-or-later"
|
|
|
|
[lints]
|
|
workspace = true
|
|
|
|
[lib]
|
|
path = "src/bedrock.rs"
|
|
|
|
[features]
|
|
default = []
|
|
schemars = ["dep:schemars"]
|
|
|
|
[dependencies]
|
|
anyhow.workspace = true
|
|
aws-sdk-bedrockruntime = { workspace = true, features = ["behavior-version-latest"] }
|
|
aws-smithy-types = {workspace = true}
|
|
futures.workspace = true
|
|
schemars = { workspace = true, optional = true }
|
|
serde.workspace = true
|
|
serde_json.workspace = true
|
|
strum.workspace = true
|
|
thiserror.workspace = true
|