Those all look great! 1. Correct! We have recently changed --label compile so it considers transient dependencies, before it would only consider direct ones. I can think of two options here. One potential option here is to introduce a new label, called "--label transient-compile". Would that be feasible implementation wise? If we go this route, I would probably rename --only-direct to --label direct-compile (of course, in a separate PR which I can also tackle).
2. The option `--only-nodes` can be nice, but often I wanted the reverse --only-nodes is really only useful with the --sink option. I think we can have two options here: a. Make --only-nodes show sinks unless the sink option is given b. Introduce a new option called --only-sinks (and then perhaps rename --only-nodes to --only-sources 3. Sounds good to me! Our option parser even supports the :keep annotation, so this should hopefully be straightforward! 4. Which commands would you like to fail? Is there any command besides the cycle one? Awesome work! I am really looking forward to these PRs! On Tue, Jun 1, 2021 at 9:33 AM Marc-André Lafortune < [email protected]> wrote: > I played around with `mix xref graph` to figure out problematic > compile-time dependencies. I am happy to report I vanquished them! > > A few improvements to `mix xref graph` that came to mind: > > 1) I define a problematic dependency as: > `A` has compile-time dependency on `B` *and* `B` has any kind of > dependency on `C`. > > There is currently no easy way that I know of to check for these > problematic dependencies. > > I coded up a `filter-leaves <integer>` options that removes "leaves", i.e. > files that have no dependencies (repeat n times). > > This way, `mix xref graph --label compile --filter-leaves 1` will give me > a list of all these cases. In my example above, if `B` has no dependencies > on `C` or other file, it is filtered out, and thus the dependency `A -> B` > never shows. > > This made it much quicker to figure out which were the deps I needed to > fix. > > It also provided me a way to add a CI check so that nobody re-introduces > such a problem. > > 2) The option `--only-nodes` can be nice, but often I wanted the reverse. > E.g.: > > ``` > $ mix xref graph --label compile > > lib/scripts/stripe_life_plans.ex > ├── lib/bobby/atomtype.ex (compile) > ├── lib/bobby/communication/behaviour.ex (compile) > ├── lib/bobby/env.ex (compile) > # ... > lib/scripts/update_mide_and_alfe_accounts.ex > ├── lib/bobby/atomtype.ex (compile) > ├── lib/bobby/communication/behaviour.ex (compile) > ├── lib/bobby/env.ex (compile) > # ... > (same pattern repeats many times over) > ``` > > Option `--only-nodes` gives me what I am *not* interested in: > > ``` > $ mix xref graph --label compile --only-nodes > lib/scripts/stripe_life_plans.ex > lib/scripts/update_mide_and_alfe_accounts.ex > # ... > ``` > > What I want is the list of sinks, not sources, so something like > `--only-sinks`, `--only-deps` or `--skip-nodes`, I'm not quite sure what a > good API here: > > ``` > $ mix xref graph --label compile --only-deps > lib/bobby/atomtype.ex > lib/bobby/communication/behaviour.ex > lib/bobby/env.ex > ``` > > I got around it with the hack `| grep '^\W' | cut -c 5- | sort | uniq`, > but I think such an option could be helpful > > 3) The `--source` and `--sink` options currently accept only a single > file, but I see no good reason for that. I had cases where I wanted to > specify multiple files (although didn't need it after --filter-leaves) > > 4) There are no meaningful exit codes. For example, `mix xref graph > --format cycles --label compile` should have an easy way to have exit code > 1 if cycles are found. I'm not too sure of the API for this either > (`--test`?) For my CI task, I modified my `grep` with `-c` option and > inverted the result, quite hacky. > > Which of these points seem worthwhile, and what would a decent API be like > for these? > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/e94a635e-393e-4f04-b1c1-7277ef492819n%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/e94a635e-393e-4f04-b1c1-7277ef492819n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BvinkNy_aL%3DC4vTtfpP7qa8-OLP%3DoA0YUouea9TjEtBQ%40mail.gmail.com.
