Currently our match predicates for when to load skills is based on crate dependencies. And, we are discussing discovering based on binary names in PATH - zulip.
But, a third category is battery packs, which live NEXT to Cargo.toml in battery-pack.toml (as of battery-pack-rs/battery-pack#118)
For error-battery-pack, it's not such a big deal since we would expect to see error related dependencies. This lets us load skills via crate match.
However, i'm also working on skills for ci-battery-pack, which is more awkward since very few of them have corresponding crate dependencies. The pack is mostly CI templates. However, having skills for how to set up trusted publishing is very useful (since it requires actions on crates.io, etc).
Proposal
We should also respect battery-pack.toml as a skill source and then load from a given battery-pack's crates.io crate tarball.
This was proposed in relation to PATH dependencies in zulip
# crates
predicate = "depends-on('foo')"
# binary
predicate = "installed('binary')"
which we could extend to:
predicate = "battery-pack('error')"
Currently our match predicates for when to load skills is based on crate dependencies. And, we are discussing discovering based on binary names in PATH - zulip.
But, a third category is battery packs, which live NEXT to
Cargo.tomlinbattery-pack.toml(as of battery-pack-rs/battery-pack#118)For error-battery-pack, it's not such a big deal since we would expect to see error related dependencies. This lets us load skills via crate match.
However, i'm also working on skills for
ci-battery-pack, which is more awkward since very few of them have corresponding crate dependencies. The pack is mostly CI templates. However, having skills for how to set up trusted publishing is very useful (since it requires actions on crates.io, etc).Proposal
We should also respect
battery-pack.tomlas a skill source and then load from a given battery-pack's crates.io crate tarball.This was proposed in relation to PATH dependencies in zulip
which we could extend to: