flow_view_deps backward

[moodymudskipper]

Starting from a function, link to all functions that depend on it, and recursively.

Every node is a dependency

Not sure if it's a new function or a new parameter.

New function names are already not so pretty.

[moodymudskipper]

It should be a new function, because flow_view_deps() 's scope is several packages in the general case.

I think this new function, let's name it flow_view_uses() has 2 main args : x and pkg.

x is usually a function but doesn't have to be pkg is by default the package where x sits but doesn't have to be. This way I can for example answer the question "In {dplyr}, which functions directly and indirectly depend on rlang::abort ?" by calling :

flow_view_uses(rlang::abort, "dplyr")

If I want to know what functions of my package depend on some function, maybe an unexported one, I can call

flow_view_uses(mypkg:::myfun)

[krlmlr]

I have a use case for this. Should there be an option to restrict the scope to an environment or to the current package?

[moodymudskipper]

Isn't this what my pkg arg described above would do ? I can extend it to environments, and also add an inherits = TRUE argument.

#' @param f A function
#' @param where A package name (as string), or an environment. `"pkg"` is equivalent to 
#'   `asNamespace("pkg")` with `inherits = FALSE`. This environment and by default its parents
#'   will be explored to detect uses of `f` in its functions.
#' @param inherits A boolean, used if `where` is an environment
#' @param out ...
flow_view_uses <- function(f, where = NULL, inherits = TRUE, out = NULL) {
   ...
}

[krlmlr]

Maybe decompose enumeration and dependency computation? Enumeration would be a family of functions that enumerate members of environments/namespaces/... and return a suitable data structure.

[moodymudskipper]

@krlmlr see PR for example, it is not very fancy yet but the package needs a massive cleanup and this will have to wait until then.