[Feature Request] Declarative package names for remotes

[dgkf]

Motivation

Currently, there's no way of knowing which package a remote provides in advance, which has some unfortunate downstream effects on package management. This has been a recurring challenge in an enterprise setting where remotes can live in private repositories or require authenticated access the remote for installation.

Just to list a few places that this has impacted my company:

• In remotes CLI prompts, packages whose names can't be fetched are listed as NA. This happens for remotes that fail to return a DESCRIPTION at a GitHub-style raw endpoint (for example when behind a proxy or requiring authentication).
• Using renv, all remotes are downloaded because the package can't be determined in advance. Regardless of dependency settings, all remotes are downloaded. If remotes are unreachable, this emits warnings to the user even though the remotes are unnecessary for their dependency preference.

Feature Request:

Introduce optional, declarative package name syntax

For GitHub remotes, the package=org/repo syntax is already introduced. As a start, I was wondering if you'd be open to adopting similar syntax for all remotes.

Brief aside for a personal opinion:

If syntax is still up for debate, I would lean toward package (org/repo) which mirrors the existing dependency syntax using the remote in place of a version number. This style didn't seem to be discussed in the initial PR or issue, but seems to me to be the more natural fit for this information.

Transition roadmap

Having a known package name would help make tools that handle installation more robust. However, tools cannot make full use of this feature unless it is ubiquitous. With that in mind, I was wondering whether you would be interested in making it a requirement that the package name be either annotated (<package> (org/repo)) or assumed (eg org/<repo> is assumed to be a package called <repo>), and would be open to a roadmap for transitioning to that behavior.

[gaborcsardi]

Thanks for the suggestion! We are focusing on https://github.com/r-lib/pak, so we are not going to add many new features to remotes. Does pak work for your use case?

[dgkf]

The primary driver for this is to mitigate warnings when remotes can't be accessed when managing an environment with renv.

Whether it's remotes or pak handling the fetching of packages, I think the central issue is that the remote syntax would still need to provide the package name in some way to avoid unnecessary attempts to pull (possibly inaccessible) remotes. It's not so much an issue with remotes internals, but rather what information is available in the DESCRIPTION syntax popularized by remotes - whether that's used by remotes or pak.

In the meantime, let me investigate whether we still see the issue when pak is enabled as the backend for renv and get back to you.

Feel free to migrate the issue to pak if it makes more sense there. I wasn't aware that there was this much overlap between the two.

[gaborcsardi]

AFAIK renv does not use the remotes package, so if you need this in renv, then I am afraid that you need to "fix" it in renv.

[dgkf]

They still rely on the syntax used in DESCRIPTION's Remote field, right?

How would I go about proposing a change to the DESCRIPTION's Remote syntax to expose this information?

I don't mind contributing support for a new syntax to renv (or other packages), but the rest of the ecosystem would also need to accommodate that syntax so that installing with remotes/pak/devtools doesn't break for packages that adopt that syntax. Do you know where would be the right place to propose these types of consensus remotes specification changes?

[gaborcsardi]

pak already supports this for the remote types that need it: https://pak.r-lib.org/reference/pak_package_sources.html#package-names

IDK if renv supports anything like this.

[dgkf]

Ah excellent - great news! Then let me try that out!

[dgkf]

Thanks for the suggestion, @gaborcsardi - I had a chance to try this out today. The declarative syntax used by pak is definitely an improvement, but from what I can tell it doesn't currently support git refs?

I saw this merged recently into pkgdepends, which seems to be geared toward GitHub. Are there plans to support git refs generally? At my place of work we use GitLab, which is a barrier to adopting pak as the renv backend at the moment.

Let me know if this is better suited toward a issue on pak/pkgdepends and I can move the discussion over there

[gaborcsardi]

pak will support git repos soonish.

[dgkf]

Awesome - I'll be looking out for it. pak looks like it will be the preferred solution for this.