`use_dev_package` does not recognise "RemoteSubdir" description field

[Jonathan-Aron-LDN]

When a github (or gitlab/bitbucket) repo stores a package in a subdirectory use_dev_package sets the "Remotes" field to "OWNER/REPO" which causes remotes::install_deps() and pak::local_install_deps() to fail because the package is not located where the "Remotes" field says it is. It seems like a quick fix could be achieved by editing the top of the function as below. Happy to make a pull request if people agree this would be a good change.

The package I was trying to depend on is here https://github.com/GAMS-dev/gdxrrw, with the R package located in the "gdxrrw" subdirectory.

  remote <- as.list(desc$get(c("RemoteType", 
                               "RemoteUsername",
                               "RemoteRepo",
                               "RemoteSubdir")))
  is_recognized_remote <- all(map_lgl(setdiff(remote, "RemoteSubdir"), 
                                      ~is_string(.x) && !is.na(.x)))
  if (is_recognized_remote) {
    if (!identical(remote$RemoteType, "github")) {
      remote$RemoteUsername <- paste0(remote$RemoteType, 
                                      "::", remote$RemoteUsername)
    }
    remote_base <- paste0(remote$RemoteUsername, "/", remote$RemoteRepo)
    if (is.na(remote$RemoteSubdir)) {
      return(remote_base)
    } else {
      return(paste0(remote_base, "/", remote$RemoteSubdir))
    }
  }

https://github.com/r-lib/usethis/blob/b9acf67511ffe165d9c42ef7ab9fab7ff5718eac/R/package.R#L83

[jennybc]

This phenomenon has come up before (e.g. #789) and affects many more functions than use_dev_package(). In general, at this point, usethis has practically no support for the workflow where someone is developing a package in a subdirectory of a repo.

I guess that could change at some point, but it's not a near-term priority.

[Jonathan-Aron-LDN]

Thanks for the response and sorry for the delay in my reply - I can see that fully supporting the development of a package in a subdirectory would require a fair bit of work, but my use case is just to depend on this kind of package, which I think is a distinct issue that would only require changing this one function (obviously you would be much more qualified to assess this).

In any case, I accept that this is a pretty minor issue with an obvious workaround so don't want to take up your time addressing it.

[hadley]

@Jonathan-Aron-LDN if you think a simple fix is possible, I think a PR is the next step forward. That way it's easier for us to evaluate exactly what you're proposing.