adding support for github packages (#22) #27
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will ultimately add full support for github packages.
(Edit: please don't merge yet, I cannot change it to draft somehow)resolve
GitHub packages need to have the form
user/repo
.get_snapshot_dependencies()
checks for a slash in the package name and then either forwards the request to.get_snapshot_dependencies_cran()
or
.get_snapshot_dependencies_gh()`. (I think this kind of structure allows to later also include other sources)system_requirements_gh()
is almost a one to one copy ofremotes::system_requirements()
to not depend on a json parser package, I also added the simple remotes parserjson.R
pkg_dep_df$x_version
is the commit sha for github packages. We need to drag this along so I thought this is the best placeIn #22 (comment) you mention to move the github packages to
output$noncran_pgs
. Should this only be the name of the packages or the whole dependency data.frame?(I assume this might clarify when I move to the docker stuff)I ignored this for now. GitHub packages are not treated differently in granlist. They remain identifiable via therepo/pkg
scheme. Open to change that, but this was the least intrusive change to code I could think ofremotes
along the way (I think better thandevtools
)~~ remotes only exists since 2016.devtools
is now added to the list of original packages if a gh package is detectedexport granlist
install_order
.install_from_github()
to headerdockerize
nothing to do here
Points to discuss
recreating the version of devtools might be overkill? Alternative would be to just install the current version of
remotes
.Disadvantage: i think this would be quite intrusive in the code.