Open czeildi opened 6 years ago
I'd be open to discussing a better solution here. I think packrat::with_extlib()
is not really the best solution here; there is likely something a little more ergonomic we could do.
I wonder if the simplest solution might be the right solution -- just provide some simple mechanism for putting the user library on the library search path, so that library(pkgdown)
can find pkgdown
in the user library even if not installed in the Packrat private library.
There's also packrat::opts$external.packages()
, which is a 'smarter' version of the above where we attempt to symlink user packages into packrat/lib-ext
, which we do always put on the library search path.
Summary: discuss a user-friendly way to use external r packages in a project where r package dependencies are tracked w packrat.
First case: a team collaborates on a project w
packrat
and one of the team members would like to use a package not closely related to the project likecolorout
. Afaik you can add this package as external package but then it would be required as external package for all project members. You can work around this by manipulating .Rprofile files but it is quite cumbersome.Second case: There are some "meta" packages which do not necessarily have place as project dependencies like
usethis
,lintr
,goodpractice
,covr
,pkgdown
etc. I take advantage of these packages in almost all of my project but I do not necessarily want to add them as dependencies. I can usepackrat::with_extlib
but I run into the issue that it is not enough to specify the main package likepkgdown
but also all their dependencies not present in my project which varies and makes it somewhat cumbersome to use. I think we could automate this.tagging @kevinushey as the developer of
packrat
- what do you think? Is there already solution I missed?