'bob ls --all' does not show indirect dependencies

[gruberchr]

According to the documentation bob ls with option --all should "show indirect dependencies too". But it seems that bob ls --all shows the same results as bob ls, only direct dependencies.

Bob version: 0.25.1
Python version 3.13.3

AFAIKS in this code line package.items() only returns the direct dependencies. Therefore, child.direct is always True in the next code line, and self.showAll is useless.

[jkloetzke]

Hmm, I cannot reproduce. For example, if I use the basement project:

basement/tests/linux$ bob ls buildall/devel::sandbox | wc -l
39
basement/tests/linux$ bob ls buildall/devel::sandbox -a | wc -l
51

Looking at the diff it shows the expected transitive -tgt packages that are provided transitive dependencies:

diff -u <(bob ls buildall/devel::sandbox) <(bob ls buildall/devel::sandbox -a)
--- /dev/fd/63  2025-06-04 21:17:59.916321833 +0200
+++ /dev/fd/62  2025-06-04 21:17:59.920321866 +0200
@@ -1,5 +1,6 @@
 core::coreutils
 core::util-linux
+core::util-linux-tgt
 devel::autotools
 devel::binutils
 devel::bison
@@ -20,6 +21,17 @@
 devel::pkg-config-tool
 devel::texinfo
 editors::ed
+libs::gmp-tgt
+libs::isl-tgt
+libs::libcap-tgt
+libs::mpc-tgt
+libs::mpfr-tgt
+libs::ncurses-tgt
+libs::openssl-tgt
+libs::pcre-lib-1-tgt
+libs::readline-tgt
+libs::zlib-tgt
+net::curl-tgt
 net::make-ca
 perl::perl
 python::python3-minimal

There is also #187 which talks about tools that are indeed not shown with --all. Is it that what you're missing by any chance?

[gruberchr]

What is the basement project?

I checked that with the recipe tree in bob/test/black-box/misc-ls instead and could not reproduce the problem there either.

It seems to be a special issue in my case, but it isn't related to #187.

I'd like to debug this problem. Could you give me some advice?

[jkloetzke]

What is the basement project?

The basement project can be found here: https://github.com/BobBuildTool/basement

I checked that with the recipe tree in bob/test/black-box/misc-ls instead and could not reproduce the problem there either.

It seems to be a special issue in my case, but it isn't related to #187.
Ok. Good.

I'd like to debug this problem. Could you give me some advice?

I think you could look first if there are more direct packages listed than expected. That would be a bug. If the package is listed explicitly in the depends section, it will always be a direct dependency, even if it is also provided as indirect dependency. On the other hand, if you miss certain indirect dependencies, check that these are correctly provided by provideDeps.

If you have a smoking gun, it would be nice if you could minimize it so that I can have a look.

[gruberchr]

I found the reason for my observation. The missing indirect dependencies are not shown because they are not provided upstream with the provideDeps keyword.

Is this intended behavior?

At least this is not obvious from the Bob documentation. Does bob ls --all always show indirect dependencies only if they are provided with the provideDeps keyword? The very brief documentation of the --all option only says "Show indirect dependencies too".

[jkloetzke]

Right. I have to admit the naming is confusing. But fundamentally, this is working as intended.

The ls command shows all the packages that are available to a package at build time. To see all transitive dependencies, something like bob ls -d <package>//* will walk the whole dependency tree. The documentation is still from the early stages of the project and certainly needs some improvement.

I'm not yet sure how to name these things properly. We have the following things:

• The dependencies of a recipe that are named in depends. -> shown by bob ls
• The dependencies that a package sees at build time. This is comprised of the dependencies named in the recipe plus anything implicitly gained via provideDeps. This latter requires that deps is part of use, which is the default. -> shown by bob ls -a.
• Transitive dependencies that are not available to the package build script because they have not been passed back via provideDeps.
• Dependencies to tools and the sandbox. They are inherited from recipes that are above in the dependency tree. Those are currently invisible in bob ls.

The naming seems to be largely incoherent throughout the documentation. Currently, I can think of the following terms:

• direct dependency - like now, the stuff that is in the recipe depends section
• indirect dependency - dependencies of a package that were gained from its provideDeps
• transitive dependency - the stuff that is reachable by recursively traversing the depends section
• ambient dependency - The tools and sandbox that were inherited from recipes that are above in the dependency tree.

I thought about using "provided dependency" but it is unclear what this means. Is it what is named in provideDeps or is it what a package gathered from its direct dependencies by their provideDeps? But I'm still not convinced by "indirect dependency" either. Any suggestion is welcome.