Transitive dependencies & Argus

Troubleshooting & how to
1

I’ve been trying out Argus after reading the blogpost by @pepicrft a bit yesterday and today. I can’t get `argus trace graph` to output dependencies. I get a list of all targets, but everything looks like this with an empty array for dependencies:

{
      "dependencies" : [

      ],
      "guid" : "ab604ffba9357862d2626287e9ac0e144f2596597784a9653e4de6df63d1e942",
      "isWrapper" : false,
      "name" : "_NumericsShims"
    }

My other relation question is about the correctness of Tuist’s project generation in regards to linking.

Given this project manifest:

.target(
            name: "TransDepsSample",
            destinations: .iOS,
            product: .app,
            dependencies: [
                .target(name: "MyModule"),
            ]
        ),
        .target(
            name: "MyModule",
            destinations: .iOS,
            product: .framework,
            buildableFolders: [
                "TransDepsSample/MyModule"
            ],
            dependencies: [
                .external(name: "Regressor")
            ]
        ),

Argus will report:

MyModule declares ComplexModule but never imports it
  -> Consider removing: MyModule -> ComplexModule

MyModule declares Numerics but never imports it
  -> Consider removing: MyModule -> Numerics

MyModule declares RealModule but never imports it
  -> Consider removing: MyModule -> RealModule

MyModule declares _NumericsShims but never imports it
  -> Consider removing: MyModule -> _NumericsShims

Bildschirmfoto 2025-12-15 um 14.10.00
Bildschirmfoto 2025-12-15 um 14.10.001072×344 41.1 KB

If I manually remove these transitive dependencies it also compiles. So I’m wondering, if it’s correct that Tuist adds these transitive dependencies here when generating the project.

TransDepsSample.zip (2.1 MB)

2

I’m looking into this, it should definitively show dependencies. Both, implicit and redundant dependency detections is currently yielding false positives, so I recommend to use Tuist’s built-in solution for now, since this one builds on the graph of your generated project.

I’ll report back with my findings.

If I manually remove these transitive dependencies it also compiles. So I’m wondering, if it’s correct that Tuist adds these transitive dependencies here when generating the project.

The linking is correct. MyModule is a linking boundary, so all the static direct and transitive dependencies need to be linked there. If you remove them things still work because of… DerivedData, but the correct configuration is the one that you see. It shouldn’t tell you though that you are not importing them and therefore you should remove them. That’s not accurate.

3

@kaioelfke would you mind testing with with version 0.4.3?

Also, note that Argus is an experiment to learn more about what information an agent can provide with the right information, which means the final product might look very different, likely just a feature inside Tuist. If you are fine with that and want to help us with those experiments, we’d appreciate it a lot.

What are other pieces of information that you’d like to get from your builds?

4

Thanks for the clarifications. I already treated it as an experimental tool. It’s still very useful. I already improved some modularization with it.

The linking is correct. MyModule is a linking boundary, so all the static direct and transitive dependencies need to be linked there. If you remove them things still work because of… DerivedData, but the correct configuration is the one that you see. It shouldn’t tell you though that you are not importing them and therefore you should remove them. That’s not accurate.

If I remove all dependencies after tuist generate in MyModule, except Regressor and clean derived data the app still compiles and runs.

@kaioelfke would you mind testing with with version 0.4.3?

Thanks, this fixes the argus trace graph dependencies output.

The output of redundant-deps and implicit-deps now is almost the same as tuist inspect for my main app. It’s just that Argus reports 2 more (false I think) redundant imports of widget app extensions.

FastingMobile declares FastingWatch but never imports it
→ Consider removing: FastingMobile → FastingWatch

FastingMobile declares FastingWidgetExtension but never imports it
→ Consider removing: FastingMobile → FastingWidgetExtension

FastingWatch declares FastingWatchWidgetExtension but never imports it
→ Consider removing: FastingWatch → FastingWatchWidgetExtension

tuist inspect redundant-imports reports `FastingMobile redundantly depends on: FastingWatch`.

What are other pieces of information that you’d like to get from your builds?

argus trace slowest-targets and some other commands duplicate targets in the output. Is this expected? Maybe it’s iOS and watchOS?

Slowest Targets (redacted output)

  1. FastingFeature (Fasting): 51.00s (132 tasks)
  2. FastingFeature (Fasting): 34.00s (212 tasks)