Unlike other output formats, it is not recursive by default, so a
new -r option allows dependencies to also have their dependencies
listed:
child1::sub other
child1 child1::sub
mod child1
mod child2
mod ...
I think this is a more subtle problem than it looks. Because of the
module filesystem layout in hare, recursive may have two meanings.
See for example:
$ hare deps -t /usr/src/hare/stdlib/crypto
crypto crypto::argon2
crypto io
crypto errors
crypto endian
crypto crypto::math
crypto crypto::mac
crypto crypto::poly1305
crypto crypto::cipher
crypto crypto::chacha
crypto bufio
crypto bytes
$ hare deps -t /usr/src/hare/stdlib/crypto/argon2
argon2 types
argon2 io
argon2 hash
argon2 errors
argon2 endian
argon2 crypto::math
argon2 crypto::blake2b
argon2 bytes
argon2 bufio
Ideally, I should see crypto::argon2 for the second one, but because
I'm querying a directory I think this caveat is justified.
But if I wanted to point `hare deps` at a top-level directory (for
example in my package's build root!) and recursively list a module's
dependency and its sub-modules, then filtering with the first column
defeats the purpose of leveraging the hare build system. If I have to
translate this knowledge in downstream packaging I'm running an
increasing risk of getting my automatic package dependencies right.
My next patch would have introduced a -s option to recursively list
sub-module dependencies.
Example:
$ hare deps -st /usr/src/hare/stdlib/crypto
crypto::argon2 types
crypto::argon2 io
crypto::argon2 hash
crypto::argon2 errors
crypto::argon2 endian
crypto::argon2 crypto::math
crypto::argon2 crypto::blake2b
crypto::argon2 bytes
crypto::argon2 bufio
[...]
crypto crypto::argon2
crypto io
crypto errors
crypto endian
crypto crypto::math
crypto crypto::mac
crypto crypto::poly1305
crypto crypto::cipher
crypto crypto::chacha
crypto bufio
crypto bytes
So I'm making the distinction here between recursively listing
sub-modules and transitive dependencies. In general, I find it
familiar enough to require a -r option to list things recursively, and
in this context I felt -r applied best to dependencies.
<snip>
The preexisting output formats remain recursive only, leaving the
decision whether or not to change the current behavior outside the
scope of this change.
This format can easily be consumed by field-based programs such as
tsort(1) (to a t!) or the more frequent utilities like sh(1) (while
read loops) or awk(1).
A familiar example:
hare deps -rt crypto |
awk '
BEGIN { print "strict digraph deps {" }
{ print "\t\"" $1 "\" -> \"" $2 "\";" }
END { print "}" }
' |
dot -T svg >crypto.svg
The motivation is to enable module processing in package managers,
in the non-recursive mode, to derive virtual provides from the first
field and virtual requires from the second one.
jsyk, the information i've quoted here could go into the send-email
annotation, rather than the commit message (so that it's just recorded
as your motivation to patch reviewers). the way to do this is, write the
rest of the stuff in the commit message, and then when you do git
send-email, write
git send-email --annotate ...
and it'll show you your patch, and then:
unfortunately this function is going to be deleted in the rewrite of the
build driver and hare::module that i am currently working on. my
suggestion is to wait until the rewrite has been merged, and then try
using the dependency-scanning functions that will be included there in
order to write your custom function.
That was my very first hare patch, and I'm sure I will throw many more
away. The thought of trying to share logic between the -d and -t
options crossed my mind but it felt overkill. Rewriting my tiny patch
when the dependency scanner is ready is perfectly fine. Please either
CC me on the relevant thread or update this thread when it's ready.
here: https://git-send-email.io/#step-4
side note: if you print it out right, the tsort shouldn't be necessary,
since the exploration function sorts in reverse topological order anyway
(so you can print in topological order by iterating in reverse).
additionaly: beware that the -T option (build tags) has the possibility
to alter the list of dependencies that are printed (because some modules
only rely on others for testing, or under libc, etc. so you probably
actually want to create a completely custom function if you would like
to know an exhaustive list of modules that a certain module may depend
on. suggestions for this in a moment...