The main reason for doing so would be to avoid confusion about multiple private categories with the same name in the same module. This is possible if multiple .0rx declare a category with the same name.
An alternative is to qualify the output of --show-deps, e.g., the last few characters of the namespace. This would make --show-deps nondeterministic, however. Numbering the occurrences in the output also wouldn't work, because the sorting within compile-metadata might be nondeterministic; this would make the numbering change after recompiling.
I guess the main point of --show-deps is to account for the dependencies in .zeolite-module. It would be good to know internal dependencies between categories in the module being shown, so that the user is aware of indirect dependencies pulled in when using a particular category.
The main reason for doing so would be to avoid confusion about multiple private categories with the same name in the same module. This is possible if multiple
.0rx
declare a category with the same name.An alternative is to qualify the output of
--show-deps
, e.g., the last few characters of the namespace. This would make--show-deps
nondeterministic, however. Numbering the occurrences in the output also wouldn't work, because the sorting withincompile-metadata
might be nondeterministic; this would make the numbering change after recompiling.I guess the main point of
--show-deps
is to account for the dependencies in.zeolite-module
. It would be good to know internal dependencies between categories in the module being shown, so that the user is aware of indirect dependencies pulled in when using a particular category.