You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ran into this issue a few days ago---using pak conflicts with devtools::install() dependency resolution if you have previously used pak to install a dependency via a git URL. devtools tries to update packages listed in the DESCRIPTION "Remotes" tag via remotes::install_deps(), but fails because pak specified the RemoteType "git" and remotes does not recognize this type.
A related (the same?) issue was posted in r-lib/pak#653, but I think this is a compatibility issue in remotes.
I recognize that we are in a transitional time of current best practices with pak, remotes, and devtools (#808), but I haven't seen info on the timeline for devtools is transitioning to pak (which would bypass this issue) so I am wondering if it is worth resolving this issue in remotes in the meantime. It seems like having remotes treat the RemoteType "git" identically to "xgit" would resolve the issue.
The text was updated successfully, but these errors were encountered:
mkoohafkan
changed the title
pak and remotes conflict when installing from git URL
pak and remotes conflict when installing from git URL via remotes::install_deps()
Dec 19, 2024
Ran into this issue a few days ago---using
pak
conflicts withdevtools::install()
dependency resolution if you have previously usedpak
to install a dependency via a git URL.devtools
tries to update packages listed in the DESCRIPTION "Remotes" tag viaremotes::install_deps()
, but fails becausepak
specified the RemoteType "git" andremotes
does not recognize this type.A related (the same?) issue was posted in r-lib/pak#653, but I think this is a compatibility issue in
remotes
.I recognize that we are in a transitional time of current best practices with
pak
,remotes
, anddevtools
(#808), but I haven't seen info on the timeline fordevtools
is transitioning topak
(which would bypass this issue) so I am wondering if it is worth resolving this issue inremotes
in the meantime. It seems like havingremotes
treat the RemoteType "git" identically to "xgit" would resolve the issue.The text was updated successfully, but these errors were encountered: