Private Hosted Remotes in the DESCRIPTION field of a package

[rlh1994]

This issue pulls together pieces that seem to be part of a few similar issues within the package that I have read through trying to resolve the root issue. (The xckd comic of having 7 standards needed a new standard, now you have 8 standards springs to mind...). This has been discussed/I think links to #453 #448 #552 . I have checked through all these and can't seem to find a solution to install repos that are both Private AND on an alternative host.

Currently just using remotes to install packages:

• Private repos can be accessed on Github/Gitlab using PAT or authorisation in install_github() or intall_gitlab()
• Hosted instances can be specified using the host = argument in the above functions
• Private repos on a hosted instance just work combining the above two.

Currently using remotes to install as part of the Remote: of the DESCRIPTION file:

• Private repos can be accessed by the sysenv for github/lab PAT being set correctly.
• Hosted instances can be specified using the url:: method pointing directly to a zip/tar
• It is not possible to point to a private repo on a hosted instance (or where the instance required login even on the same network), the gitlab:: option doesn't allow for specifying the host, and url:: doesn't trigger the usage of the PAT key.

I have specifically noticed this when developing a meta-package on a corporate hosted Gitlab instance, which itself depends on other packages also on that instance, I can start the download using install_gitlab but it fails when it tries to download the dependant packages on the remote. Downloading each of the other packages stand-alone works using install_gitlab as these have no remote dependencies.

All file type versions of: url::https://gitlab.host.com/user/project/-/archive/master/project-master.tar lead to the file downloaded being a HTML file of the login page.

I have attempted to look through the code of the package to understand somewhat how it works but I'll be honest don't quite understand it all and am not sure exactly how it converts from the description file to the running of the functions but I think a few possible solutions, without understanding which would be easier could be:

• Allow for a more complex connector in the Remotes field of the description, something like gitlab::[email protected]/repo/name as suggested in #552 that allows you specify the host, but would also attempt the gitlab/hub auth process
• Attempt a more complex parse of the URL itself, if it contains gitlab/hub then attempt to use the gitlab/hub authorisation (this seems more complex given the reliance that the hostings have their keywords in there, and parsing the host part of the URL could be unreliable).

Either of these solutions should be able to be extended for other repo services, but I am only really familiar with gitlab/github.

[CeresBarros]

I'm not entirely sure if this is related, but I have a package hosted in a private repo in gitlab.com and tried to include it in the Remotes section of another package, while specifying correct branch for installation.

these didn't work for me:

Remotes:  gitlab::<username>/<reponame>@<branch>

Remotes: url::https://gitlab.com/<username>/<reponame>/-/blob/<commit>/<package>.tar.gz

but this did:

Remotes: git::[email protected]:<username>/<reponame>@<branch>

[jabenninghoff]

Per my note here: https://github.com/r-lib/remotes/issues/448#issuecomment-1728529534, this may be resolved by #541.