How to get a simple path from `xref graph`?

Phoenix Forum Questions / Help
, ,
1

Why is mix xref graph with a source and a sink giving me all these useless branches?

There happens to be a single path from my source to my sink, yet I get a 800+ line output.
There is only a single line where my sink appears.

Maybe this is due to some cycles? Even then most leaves don’t seem pertinent…

$ mix xref graph  --source lib/bobby/underwriting/rule/life/xyz_test.ex --sink lib/bobby_web/views/documents/life_view.ex

lib/bobby/underwriting/rule/life/xyz_test.ex
└── lib/bobby/underwriting/rule.ex (compile)
    ├── lib/bobby/policies/policy_application.ex
    │   ├── lib/bobby/accounts/account.ex
    │   │   ├── lib/bobby/accounts/midoconline_code.ex
    │   │   │   └── lib/bobby/accounts/account.ex
    │   │   ├── lib/bobby/accounts/user.ex
    │   │   │   ├── lib/bobby/accounts/account.ex
    │   │   │   ├── lib/bobby/accounts/credential.ex
    │   │   │   │   ├── lib/bobby/accounts/user.ex
    │   │   │   │   └── lib/bobby_web/endpoint.ex
    │   │   │   │       └── lib/bobby_web/router.ex
    │   │   │   │           ├── lib/bobby/Plug/authentication.ex (compile)
    │   │   │   │           │   └── lib/bobby_web/views/error_view.ex
    │   │   │   │           ├── lib/bobby/accounts.ex
    │   │   │   │           │   ├── lib/bobby/accounts/account.ex (export)
#...
    │   │   │   │           │   │   │   ├── lib/bobby/accounts/credential.ex
    │   │   │   │           │   │   │   └── lib/bobby/segment_events/event.ex (compile)
    │   │   │   │           │   │   └── lib/bobby/segment_events/suspended_account_event.ex
    │   │   │   │           │   │       ├── lib/bobby/accounts/account.ex
    │   │   │   │           │   │       └── lib/bobby/segment_events/event.ex (compile)
    │   │   │   │           │   └── lib/bobby_web/endpoint.ex
    │   │   │   │           ├── lib/bobby/policies.ex
    │   │   │   │           │   ├── lib/bobby/documents.ex
    │   │   │   │           │   │   ├── lib/bobby/documents/storage_documents.ex (export)
#...
    │   │   │   │           │   │   ├── lib/bobby_web/views/documents/life_view.ex <<<<
    │   │   │   │           │   │   │   ├── lib/bobby/accounts.ex
    │   │   │   │           │   │   │   ├── lib/bobby/policies.ex
    │   │   │   │           │   │   │   └── lib/bobby_web/views/component/component_helpers.ex (export)
    │   │   │   │           │   │   └── lib/bobby_web/views/documents/quake_view.ex
    │   │   │   │           │   │       ├── lib/bobby/accounts.ex
    │   │   │   │           │   │       ├── lib/bobby/documents.ex
#... 600 more lines that are not relevant to me!

Is there a way to get the output I want:

lib/bobby/underwriting/rule/life/AIDS_test.ex
└── lib/bobby/underwriting/rule.ex (compile)
    └── lib/bobby/policies/policy_application.ex
        └── lib/bobby/accounts/account.ex
            └── lib/bobby/accounts/user.ex
                └── lib/bobby/accounts/credential.ex
                    └── lib/bobby_web/endpoint.ex
                        └── lib/bobby_web/router.ex
                            └── lib/bobby/policies.ex
                                └── lib/bobby/documents.ex
                                    └── lib/bobby_web/views/documents/life_view.ex

(Elixir 1.11.4, Erlang/OTP 23)

2

There are likely multiple paths and perhaps even cycles, as you mentioned. We may need to add a —shortest option or similar.

2 Likes
3

Edit after misreading: Yes, such an option would be awesome.

Alternatively, --ignore-cycles would probably work too (iterate the graph but never reenter an already visited node)

4

Please open up an issue request for --shortest so we don’t forget about it.

I believe we already do that. It is just that, once you have a cycle, any node coming into any node in the cycle and any node coming out of the cycle is now part of the graph, so it blows things up quite quickly.

5

I will. I thought I might even check if I can understand the code enough to propose a PR .

Would the option --shortest as you envision it only ever present a single path?

I haven’t checked the code yet, but I imagine the graph is filtered, than mapped into a tree breadth-first, so yes cycles are already broken, but the resulting tree is not filtered again (or maybe the whole graph could be made into a tree and then filtered, I wish I knew more in graph theory)

My initial idea was to filter that tree to remove any subbranch that no longer yields to the sink.

In my example above, all of the branches except one should be filtered out.
Additionally, there are 3 branches that are shown originating from my sink (I imagine because they connect back there through a cycle) these should be filtered too.

This way could lead to multiple paths, not just the shortest, but all would be independent and fit the given criteria.

6

When we convert to a tree, we don’t print a subranch that already has already been printed. So the first time we show foo.ex, we will show its children, but the next time will only show foo.ex.