Conversation
Co-Authored-By: GPT-5.6 <codex@openai.com>
| ["src/**/*.rs"], | ||
| exclude = ["src/bin/**/*.rs"], | ||
| ), | ||
| # logger-cli is a workspace consumer of the optional observation API. Bazel |
There was a problem hiding this comment.
Isn't this going to cause issues? How do we do features in this world?
There was a problem hiding this comment.
The only way to do this is to have two distinct build targets, one with and another one without. Downstreams then depend on the one they want
For most crates features are additive and just enables more code so this is fine, but for stuff that changes behavior we'll have to be a bit careful. Transitive features for first party crates isn't really supported in Bazel but it's not that common
I'll clean this up in a follow up to make it so that only logger-cli depends on the extra feature
|
|
||
| struct Tool { | ||
| #[expect( | ||
| clippy::struct_field_names, |
There was a problem hiding this comment.
I would just allow this globally
| @@ -0,0 +1,82 @@ | |||
| load("@crates//:defs.bzl", "all_crate_deps") | |||
| load("@rules_rs//rs:rust_library.bzl", "rust_library") | |||
| load("@rules_rs//rs:rust_binary.bzl", "rust_binary") | |||
There was a problem hiding this comment.
How are you going to handle rewriting the test and binary targets for clippy etc. Should these just point to root paths and not work in isolation or will you rewrite them somehow?
There was a problem hiding this comment.
These should be using the top level ones yeah, let me update. I'd add a lint for that at some point
| rand = "0.10.2" | ||
| regex = "1.13.0" | ||
| reqwest = { version = "0.13.4", features = ["deflate", "json"] } | ||
| rusqlite = "0.32.1" |
There was a problem hiding this comment.
Remove the other dep? This is what valve uses?
2 participants
No description provided.