Allow separate "sources of truth" for R packages collected in deployment manifest

[kevinushey]

Currently, rsconnect relies on Packrat for lockfile generation, which implies that package dependencies are always inferred based on what's currently installed or available in the user's R library.

However, users might reasonably want to be able to declare their project's package requirements in other ways. For example, they may want to:

1. Override some package dependencies in a piecemeal way; e.g. use a different version on deployment, or install from a separate source,
2. Read package dependencies from a separate "source of truth" altogether; e.g. renv.lock; pkg.lock; something else.

I believe part of (1) is supported on the Connect side with some side-channels for providing packages during a deployment, but (2) could be useful for users who want to be able to declaratively state what packages are to be used during deployment.

For an implementation sketch, I think we could have a function like askManifestType() that (if appropriate) would prompt the user for the "source of truth" for R packages, and then that could be passed as a parameter to deployApp(). There could also be a mechanism for setting these via R options / environment variables if it felt appropriate, or was asked for.

This request was from a professional customer, who would like more granular control over what packages are used and installed in deployments.

[hadley]

For 2, do you think we could just use a renv.lock/pkg.lock if present? Isn't presence of those files sufficient to indicate that you want to manage the versions yourself? (TBH I had always assumed this is what rsconnect did; I didn't realise that it always re-ran packrat, even if an existing lock file already existed)

[aronatkins]

The historical reasons for running an rsconnect-time dependency scan:

1. Folks weren't using tools like Packrat or renv.
2. The target content (let's say R Markdown document) was part of a large project and required very few of its dependencies.
3. No way to separate "development" from "production" dependencies (at the time).

Using an existing lock file is compelling, especially if this is a narrowly-scoped project and we can ignore unnecessary dependencies from information in that lock file.

If folks are deploying from a "kitchen sink" project, the cost to restore the environment at deploy-time will be fairly high.

The automatic scanning has simultaneously been convenient, surprising (especially for packages without explicit in-code dependencies), and inflexible.

[hadley]

FWIW we allow python users to make this decision with the forceGeneratePythonEnvironment argument.

[mdshw5]

I'd love the ability to specify my R dependencies via an renv lockfile during deployment to Posit Connect. The existing dependency discovery via packrat has caused headaches for our team in the past. We had also assumed that renv would be the preferred solution for an RStudio product. Thanks for continuing this discussion!