Especially useful for big codebases and iteration - you can discover the subset of modules you care about when you're tuning a module's deps. You can specify name(s) or regex(es).
I also added a --jobs parameter. I apply it in the normal case as well. It was a little tricky to get right for the pruning version, but I verified there is parallelism with logging:
$ GRAPHEX_VERBOSITY=1 graphex cabal --prune-to Graphex
Discovering with num jobs = 8
Start parsing imports for Graphex
Finished parsing imports for Graphex
Start parsing imports for Graphex.Search
Start parsing imports for Graphex.LookingGlass
Start parsing imports for Graphex.Core
Finished parsing imports for Graphex.Search
Start parsing imports for Graphex.Queue
Finished parsing imports for Graphex.LookingGlass
Start parsing imports for Graphex.Core
Finished parsing imports for Graphex.Core
Finished parsing imports for Graphex.Queue
Finished parsing imports for Graphex.Core
{"attrs":{},"edges":[{"from":"Graphex","to":"Graphex.Core"},{"from":"Graphex","to":"Graphex.LookingGlass"},{"from":"Graphex","to":"Graphex.Search"},{"from":"Graphex.LookingGlass","to":"Graphex.Core"},{"from":"Graphex.Search","to":"Graphex.Queue"}],"nodes":{"Graphex":{"color":null,"label":"Graphex"},"Graphex.Core":{"color":null,"label":"Graphex.Core"},"Graphex.LookingGlass":{"color":null,"label":"Graphex.LookingGlass"},"Graphex.Queue":{"color":null,"label":"Graphex.Queue"},"Graphex.Search":{"color":null,"label":"Graphex.Search"}},"title":"Internal Package Dependencies"}
I didn't use it, but Graphex.Queue felt appropriate to be its own module.
I added graphex graph remove which removes nodes.
You can now specify -g - to use stdin for your graph JSON.
I still need to update the tests / add more.
I think the other direction of #4 can only be done with post-processing, so we have to discover the entire graph. Since we only have our imports in-hand but not who imports us, we have to parse everything.
Relevant CLI Changes
$ graphex cabal --help
Usage: graphex cabal [-j|--jobs ARG] [--prune-to ARG] [--prune-to-regex ARG]
Cabal operations
Available options:
-j,--jobs ARG Number of worker threads to use
--prune-to ARG Only discover import dependencies of the specified
module(s)
--prune-to-regex ARG Only discover import dependencies of modules that
match a regex
$ graphex graph remove --help
Usage: graphex graph remove [-r] module
Remove nodes from the graph
Available options:
-r Use regex
-h,--help Show this help text
Usage: graphex graph [-g|--graph ARG] [-r|--reverse] COMMAND
Graph operations
Available options:
-g,--graph ARG Path to graph data. Use - for stdin.
(default: "graph.json")
Solves one part of #4
Especially useful for big codebases and iteration - you can discover the subset of modules you care about when you're tuning a module's deps. You can specify name(s) or regex(es).
I also added a
--jobs
parameter. I apply it in the normal case as well. It was a little tricky to get right for the pruning version, but I verified there is parallelism with logging:I didn't use it, but
Graphex.Queue
felt appropriate to be its own module.I added
graphex graph remove
which removes nodes.You can now specify
-g -
to use stdin for your graph JSON.I still need to update the tests / add more.
I think the other direction of #4 can only be done with post-processing, so we have to discover the entire graph. Since we only have our imports in-hand but not who imports us, we have to parse everything.
Relevant CLI Changes