zkg info shows neither depends nor external_depends

[bbannier]

It would be nice if zkg info would be able to show dependencies of a package (i.e., information derived from depends and external_depends). Ideally it would even be able to include links to more information for packages from depends (e.g., links to repositories, or at least link to the package index).

I am currently working on a meta package aggregating smaller, more dedicated packages. I plan to encode that information in the meta package's depends field. In order to check whether the package can be build used without zkg (in this case: built with CMake, and used), I would like to have access to that information in zkg.meta without having to parse it myself.

I could imagine this information to be useful in other scenarios as well, e.g., to check licenses, or to debug version if multiple packages depend on the same package (but possibly in different versions).

Making it easier to view a package's external_depends could simplify e.g., package deployment.

[ckreibich]

Agree, yeah. It's a straightforward addition to cmd_info in the toplevel zkg file. Would you like to give it a go? Otherwise I'll get to it in the next few days.

[bbannier]

Would you like to give it a go? Otherwise I'll get to it in the next few days.

@ckreibich, I don't think I'll have capacity to work on this soon. I think this would be nice to have, but it is not urgent.

[bbannier]

Thinking more about this, it would actually be nice to display a full dependency tree which would include dependencies of dependencies and so on. This would be useful in a worlds of e.g., metapackages where I could see the need to debug version incompatibilities in deps of deps.

As an example, for zeek/spicy-analyzers we are in the process of moving analyzers into dedicated packages which then all depend on at least zeek/spicy-plugin. I could imagine that debugging incompatible zeek/spicy-plugin requirements to require a lot of manual checking.

[ckreibich]

I think you're building a nice stresstest for zkg's dependency handling! I'd expect it to refuse to install package constellations when any dependency, including nested ones, cannot be satisfied or collide with what's already installed.

I agree that a dependency tree view, like pipdeptree, would be useful. For the latest package versions this is fairly easy since the aggregated metadata in the package source have all needed information. For alternative versions, zkg would need to clone/checkout its way through the dependency tree. Definitely doable (it does it for installs too), just a bigger step for zkg info.