Skip to content
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

Support for named remote dependencies #794

Open
msteijaert opened this issue Apr 16, 2024 · 8 comments
Open

Support for named remote dependencies #794

msteijaert opened this issue Apr 16, 2024 · 8 comments
Labels
feature a feature request or enhancement

Comments

@msteijaert
Copy link

msteijaert commented Apr 16, 2024

The pak package supports packages names in the Remotes field.
In fact, for local dependencies that is even required, as https://pak.r-lib.org/reference/pak_package_sources.html mentions:

For local:: dependencies, you always need to specify the package name explicitly. E.g. pins=local::~/works/pins.

In an example package, I could confirm that this is compatible with e.g., pak::pkg_sysreqs() and pak::local_deps(). However, when I use the same package (and DESCRIPTION file) with remotes::install_local(), I get an error:

> remotes::install_local("/path/to/myPackage")
Error: Failed to install 'myPackage' from local:
  Unknown remote type: myDependency=local
  object 'myDependency=local_remote' of mode 'function' was not found

Is it possible to add support for this explicit name to the remotes package?

@gaborcsardi
Copy link
Member

Can you show an example? E.g. a package in a GitHub repository that does not work with with remotes?

@gaborcsardi gaborcsardi added the feature a feature request or enhancement label Apr 16, 2024
@msteijaert
Copy link
Author

Can you show an example? E.g. a package in a GitHub repository that does not work with with remotes?

@gaborcsardi , I have added a few example packages here: https://github.com/msteijaert/r_dependency_examples
After setting the root directory of my local clone of this repository as my working directory, I can successfully run pak::local_deps("~/git/r_dependency_examples/package1") . However, when I run remotes::install_local("~/git/r_dependency_examples/package1"), I get an error:

> remotes::install_local("~/git/r_dependency_examples/package1")
Error: Failed to install 'package1' from local:
  Unknown remote type: package2=local
  object 'package2=local_remote' of mode 'function' was not found

I have retried with full paths, but the error persists.

If I remove the package names from the Remotes field, remotes::install_local works fine, but pak::local_deps is no longer able to find the remotes matching the package names in the Imports field.

@dylanhmorris
Copy link

dylanhmorris commented Apr 18, 2024

Noting that I have also run into this incompatibility between the Remotes: field syntax that remotes expects and the corresponding syntax that pak expects. Workarounds are possible but I agree that supporting named local dependencies in remotes would be a nice feature.

I note that remotes does appear to support named Github dependencies if they are specified as:

Remotes:
    <name>=<repo>[/<subdir>]

(link to example)

but not if they are specified in the form:

Remotes:
    <name>=github::<repo>[/<subdir>]

(link to example)

I have modified @msteijaert's example package1 to demonstrate (see links above).

The non-working example throws a similar error to that thrown with a named local:: remote.

> remotes::install_local('.')
Error: Failed to install 'package5' from local:
  Unknown remote type: shinyproxy=github
  object 'shinyproxy=github_remote' of mode 'function' was not found

@gaborcsardi
Copy link
Member

Out of curiosity, why are you using remotes? Why not use pak instead?

@msteijaert
Copy link
Author

Out of curiosity, why are you using remotes? Why not use pak instead?

I like to be able to use the same package with both pak and remotes. E.g., that allows me to switch between pak and remotes depending on the use-case (e.g. local development, CI/CD, dockerized deployment of Shiny apps). The two main advantages of remotes are that it is lightweight and that it allows installing specific versions for certain packages.

@gaborcsardi
Copy link
Member

The two main advantages of remotes are that it is lightweight and that it allows installing specific versions for certain packages.

pak has no dependencies and we provide self-contained pak binaries that even bundle the SSL certificates.

pak also supports installing specific versions of packages.

@msteijaert
Copy link
Author

pak also supports installing specific versions of packages.

Thanks for this information. I could not find it in the pak documentation, but indeed it turns out that one can use
pak::pkg_install("[email protected]") as a replacement for remotes::install_version("data.table",version = "1.15.0").

@gaborcsardi
Copy link
Member

I could not find it in the pak documentation

See https://pak.r-lib.org/reference/pak_package_sources.html#cran-packages-cran-

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants