Notes on dependency and lockfile management

[nealrichardson]

Don't want to require double bookkeeping everywhere, especially with manifest.json since it is Connect-only and requires Connect tooling to generate. But:

• If repositories are private, GitHub Actions can't generate the right lockfile from pyproject.toml or R files, unless the repos are set there. (If PPM, they have OIDC support.) This is a problem unless/until Connect can support installing from pyproject.toml etc. without a requirements.txt
• Python: There was some issue using uv to turn uv.lock into requirements.txt (todo write an issue)

In R,

• rsconnect::writeManifest() can take a renv.lock, but it requires packages to be installed, which may not always be possible.
• renv::renv_lockfile_from_manifest() exists to go manifest to renv.lock, but not the other way.
• Publisher has typescript code to convert renv.lock to manifest.json
• There is also a pak lockfile? https://pak.r-lib.org/reference/lockfile_create.html

For all languages:

• If a manifest.json exists, use it. Assume user knows about it and updates it out of band. (Support deploying with a manifest.json #16)
• Else, if a lockfile exists (uv.lock, renv.lock, others), use it. Assume that user is managing the lockfile on their own (pre-commit hook, other workflow, etc.) (Translate renv.lock to manifest.json #22)
• Else, if a project requirements file exists (pyproject.toml, DESCRIPTION, etc.), the action should generate a lockfile with it and use that. Assumption is that private packages or repos are either not used by the project or are configured in the workflow. (needs issue to pick up DESCRIPTION file)