PR #1318 helps alleviate the problem where lockfile and local library are out of sync by ignoring the lockfile and use only local library DESCRIPTION data.
Still, on the other hand, there are still valid use cases where the existing lockfile should be enough to allow a deployment without the need of the local system packages to be in sync.
We can build DESCRIPTION-like records from the lockfile data itself, the lockfile has Package, Version, Source, Repository, and remote fields. We could synthesize a minimal description record from those fields without needing the package to be locally installed at all. This is what is asked for in #1046 was asking for ("the renv.lock file should have all the information we need").
This is a cleaner long-term solution and what truly solves the CI/CD use case (no library needed at all), but it's a bigger change (thus #1318 helping on the short term) we'd need to confirm that Connect doesn't depend on any DESCRIPTION fields beyond what the lockfile provides.
PR #1318 helps alleviate the problem where lockfile and local library are out of sync by ignoring the lockfile and use only local library DESCRIPTION data.
Still, on the other hand, there are still valid use cases where the existing lockfile should be enough to allow a deployment without the need of the local system packages to be in sync.
We can build DESCRIPTION-like records from the lockfile data itself, the lockfile has
Package, Version, Source, Repository, and remotefields. We could synthesize a minimal description record from those fields without needing the package to be locally installed at all. This is what is asked for in #1046 was asking for ("the renv.lock file should have all the information we need").This is a cleaner long-term solution and what truly solves the CI/CD use case (no library needed at all), but it's a bigger change (thus #1318 helping on the short term) we'd need to confirm that Connect doesn't depend on any DESCRIPTION fields beyond what the lockfile provides.