Part of #294.
Depends on: nothing.
What happens
A crate can describe its plugin in its Cargo.toml, under [package.metadata.symposium], the form the documentation leads with. If anything in that block is malformed, the entire block is discarded and the author is never told in a way they will see.
It is not truly silent: a warning goes to Symposium's log file. But it never reaches the terminal, not even with -v, and plugin validate cannot interpret this form: pointed at a crate directory it reports finding nothing, and pointed at the Cargo.toml it fails on the surrounding package key. So the author's realistic feedback is that nothing happens, while status still lists the plugin as present.
The same mistake in a registry manifest is reported on the terminal and fails plugin validate outright. The two forms disagree about how strict to be, and the lenient one is the form authors are told to use.
The drop is whole-block, not per-key. One bad key removes everything the crate declared, including declarations that are perfectly valid.
How to see it
# needs: cargo-agents and an isolated SYMPOSIUM_HOME, same shape as #289, plus
# [plugins]
# auto-enable = ["<the path-dependency crate>"]
# so the crate is enabled and you are looking at a manifest problem, not a consent one
# in the path dependency's Cargo.toml, one valid declaration and one mistyped key.
# the real key is [subcommand.<name>]; `subcommands` is not a field:
#
# [package.metadata.symposium.subcommand.hello]
# description = "a valid declaration"
# command = "hello"
#
# [[package.metadata.symposium.subcommands]]
# name = "oops"
SYMPOSIUM_HOME=/tmp/iso cargo agents sync
# -> no applicable skills found for workspace dependencies
SYMPOSIUM_HOME=/tmp/iso cargo agents --help
# -> `hello` does not appear: the valid declaration went with the bad key
SYMPOSIUM_HOME=/tmp/iso cargo agents status
# -> the plugin is listed; nothing mentions the discarded manifest
# the warning exists, but only here:
grep -i "malformed" /tmp/iso/logs/symposium-*.log
# now put the SAME mistyped key in a registry manifest at /tmp/reg/broken/SYMPOSIUM.toml
# (the entry from #289 is valid, so validating it would pass and prove nothing):
SYMPOSIUM_HOME=/tmp/iso cargo agents plugin validate /tmp/reg
# -> <unknown> (plugin): loading plugin from .../SYMPOSIUM.toml and exit 1
Done when
- An author who malforms
[package.metadata.symposium] finds out without reading a log file.
- Some command can be pointed at a crate and report what Symposium makes of its manifest.
- Either the whole-block drop is narrowed so one bad key does not discard valid declarations, or the message says plainly that everything the crate declared was ignored.
Part of #294.
Depends on: nothing.
What happens
A crate can describe its plugin in its
Cargo.toml, under[package.metadata.symposium], the form the documentation leads with. If anything in that block is malformed, the entire block is discarded and the author is never told in a way they will see.It is not truly silent: a warning goes to Symposium's log file. But it never reaches the terminal, not even with
-v, andplugin validatecannot interpret this form: pointed at a crate directory it reports finding nothing, and pointed at theCargo.tomlit fails on the surroundingpackagekey. So the author's realistic feedback is that nothing happens, whilestatusstill lists the plugin as present.The same mistake in a registry manifest is reported on the terminal and fails
plugin validateoutright. The two forms disagree about how strict to be, and the lenient one is the form authors are told to use.The drop is whole-block, not per-key. One bad key removes everything the crate declared, including declarations that are perfectly valid.
How to see it
Done when
[package.metadata.symposium]finds out without reading a log file.