Notes on dependency and lockfile management

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. (#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.) (#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)

Start by reviewing the proposed selection order in this issue, related issues #16 and #22, and the Publisher conversion code at extensions/vscode/src/publish/rPackageDescriptions.ts. Compare the referenced rsconnect, renv, pak, and uv workflows, then define the implementation entry points and acceptance tests for using manifest.json, existing lockfiles, or generated lockfiles.