Support renv profiles

[jonkeane]

Support renv profiles and custom renv file locations specified with the RENV_PATHS_LOCKFILE environment variable

Fixes #1122

[nealrichardson]

Why do we need to copy it at all? Why can't we use it where it lives? It's a little odd to me that this function would alter the contents of the current working directory.

[jonkeane]

One thing that's confusing about this is that it's actually not copying it into the working directory, but actually into the temporary directory the rsconnect creates and copies files over to a temporary directory

rsconnect/R/appDependencies.R

Lines 130 to 135 in c704931

	bundleDir <- bundleAppDir(
	appDir = appDir,
	appFiles = appFiles,
	appMode = appMetadata$appMode
	)
	defer(unlink(bundleDir, recursive = TRUE))

which calls

rsconnect/R/bundle.R

Lines 1 to 12 in c704931

	# Given a path to an directory and a list of files in that directory, copies
	# those files to a new temporary directory. Performs some small modifications
	# in this process, including renaming single-file Shiny apps to "app.R" and
	# stripping packrat and renv commands from .Rprofile. Returns the path to the
	# temporary directory.
	bundleAppDir <- function(
	appDir,
	appFiles,
	appPrimaryDoc = NULL,
	appMode = NULL,
	verbose = FALSE
	) {

But thinking about this more, we might need to make sure that we can handle relative paths in RENV_PATHS_LOCKFILE since when this is run inside of the temp bundle dir, those might not work (e.g. if RENV_PATHS_LOCKFILE="../renv.lock" and the app is at /home/jonkeane/Documents/myapp/subdir/, my lock file is at /home/jonkeane/Documents/myapp/renv.lock we don't want the target of this copy to be /tmp/.../renv.lock

[nealrichardson]

If I run this function twice, I'm going to get this warning, even though the files themselves are identical. Should we be checking the contents of the files instead?

[jonkeane]

I can add checking the contents, but running user-exported commands in rsconnect, this path should not alter someone's app directory (so this shouldn't happen in practice unless someone calls rsconnect:::ensureRenvLockFile (or the other internal functions that always operate on the temp bundle dir