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

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.

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?

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?

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.

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".

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.

So I've came up with the following terms:

declared (direct) dependencies: named in the "depends" section
provided dependencies: listed in provideDeps (providing side)
injected dependencies: received through provideDeps (receiving side)
immediate dependencies: declared and injected dependencies
ambient dependencies: tools, sandbox and interpreters inherited from downstream recipes
transitive dependencies: recursively reachable packages

I hope this clarifies the situation. IF you agree I'll merge #718 and close this issue.

I had a look on PR #718 and it looks mostly fine to me. Introducing the section Dependency terminology (configuration-principle-dependencies) is very helpful. The selected terms declared, provided, injected, transitive and ambient sound meaningful.

Only the term immediate dependencies is not that expressive. Perhaps build dependencies fits better, since these are the dependencies passed to the build script (BOB_DEP_PATHS). Alternatively, an additional term may not be necessary. The combination declared or injected may be sufficient.

doc: unify dependency terminology

Fix dependency naming (#718)

Thanks. You're right. The "immediate dependencies" term was not used too much and I replaced it accordingly.

AFAICS the term "immediate" is still used at two positions in the function descriptions:

Maybe this was not intended.

Thanks for the hint. Indeed, this was not intentional. Fixed in 93c141d.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

jkloetzke commented on Jun 4, 2025

gruberchr commented on Jun 5, 2025

jkloetzke commented on Jun 5, 2025

gruberchr commented on Jun 18, 2025

jkloetzke commented on Jun 22, 2025

jkloetzke commented on Oct 6, 2026

gruberchr commented on Oct 7, 2026

jkloetzke commented on Oct 8, 2026

gruberchr commented on Oct 9, 2026

jkloetzke commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions