-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: support for subdir spec with Git remote #646
Comments
Yes, this was indeed not implemented because it needs new syntax. We could take the part ending with Or we could have a double
|
Just chiming in as there might be some opportunity for standardizing here. In r-lib/pkgdepends#353, we used Not sure if this is being overly defensive, but you may consider namespacing a parameter name I also suggested a more literal syntax in that thread (r-lib/pkgdepends#353 (comment)), and I'm still rather partial to that as a verbose solution. @gaborcsardi mentioned some issues, and I'm not sure I totally groked the downsides - especially if tools start expecting really bespoke syntax. |
I have no good intuition whether that’s a problem: I have never seen this usage for repo URIs, and I am confident that it’s going to be very rare, if it exists at all, but it’s still technically breaking backwards compatibility, and somebody, somewhere might be relying on this behaviour. |
It is currently not possible to install a package inside a Git subdirectory with the
git::
remote.As an example of this, the ‘ArvadosR’ package is currently hosted at https://github.com/arvados/arvados/tree/main/sdk/R. However, it cannot be installed by
pak::pkg_install()
. For instance, the following fails (since ‘pak’ attempts to treat the entire specification as a Git repository):(For this particular example, the
github::
remote type could be used instead. However, we have a use-case with internally hosted packages that require the use of thegit::
remote.)I’m not sure how to best implement this — e.g. the above syntax would be ambiguous. Maybe via a parameter? I.e.
(cf. r-lib/remotes#777, although that turned out to be different.)
The text was updated successfully, but these errors were encountered: