Dependency analysis

[jennybc]

Interesting in a direct sense, i.e. for usethis specifically, and also possibly as a function to expose for active package. Results would need to be reported in a more usable form.

http://crandeps.r-pkg.org/deps/usethis

[jennybc]

For local/dev use, helpful snippet from @gaborcsardi:

r <- pkgdepends::remotes()$new("r-lib/usethis", lib = tempfile())
r$solve()
r$draw_tree()

[jennybc]

Possible pre-release check: diff the dependencies of candidate vs. previous CRAN release.

@gaborcsardi brings up that this is rather late to think about this. Do it as you go, i.e. as you add packages to DESCRIPTION?

[gaborcsardi]

Btw. to do it for your locally installed version, you need sg cumbersome currently:

r <- pkgdepends::remotes$new("installed::/Users/gaborcsardi/r_pkgs/usethis", lib = tempfile())

I.e. the actual installation location...

[jennybc]

Removed from the milestone, revisit for next release, when devtools scene is even more settled.

[jennybc]

r <- pkgdepends::remotes$new("installed::/Users/jenny/resources/R/library/usethis", lib = tempfile())
r$solve()
r$draw_tree()

[hadley]

Thinking about it more, analysis of CRAN dependency graph is probably slightly better than local, but there's generally unlikely to be much difference.

[jennybc]

But when I start to dig into the dependency graph, it is often because / when several packages are in a dev state.

I know we hope we won't have so many things that depend on dev versions of each in the future and yet ...

[hadley]

As in #310, we should also expose this information when you take an action that would significantly change the depency graph.

[jennybc]

A successful dependency analysis on usethis itself (see #1223):

# devtools::install_github("r-lib/pkgdepends")
library(pkgdepends)
library(gert)
#> Linking to libgit2 v1.0.1, ssh support: YES
#> Global config: /Users/jenny/.gitconfig
#> Default user: Jenny Bryan <[email protected]>

# should work but doesn't currently
# options(pkg.show_progress = FALSE)

f <- function() {
  pd <- new_pkg_deps("local::.")
  suppressMessages(pd$solve())
  dat <- pd$get_resolution()
  sort(unique(dat$ref))
}

git_branch_checkout("inline-rematch2")
#> <git repository>: /Users/jenny/rrr/usethis[@inline-rematch2]
deps_now <- f()
length(deps_now)
#> [1] 33

git_branch_checkout("master")
#> <git repository>: /Users/jenny/rrr/usethis[@master]
deps_then <- f()
length(deps_then)
#> [1] 41

setdiff(deps_then, deps_now)
#> [1] "digest"    "ellipsis"  "pillar"    "pkgconfig" "rematch2"  "tibble"   
#> [7] "utf8"      "vctrs"

^{Created on 2020-11-13 by the reprex package (v0.3.0.9001)}

[hadley]

Now mostly handled by pak::pkg_deps("local::."), so I think we can probably implement this once current pak is on CRAN.

[alexpghayes]

A separate possible use case for this is figuring out the order to send things to CRAN. I currently have ~5 or so dev packages that all depend on each other, and it's a minor issue to figure out the order to send them to CRAN, but it might be nice to have some additional tools to help with this (see also: that sad feeling when you get a package all cleaned up and ready to send off, only to realize it depends on something messy that will take some work to fix up, which also depends on something else that needs cleanup, etc, etc).

For example, it would be nice to turn the cli::tree returned from pak::pkg_deps() into an igraph graph. Then we could plot with visNetwork, or use mst to find an order to submit packages to CRAN.

I understand this is far from critical but just want to briefly pitch it. Would be nice to a step in the package dev workflow where you get warned/reminded about depending on other dev work.

[jennybc]

@alexpghayes I think all of that is a potential feature request for pkgdepends. usethis would, at most, expose some functionality that fundamentally lives there.