-
Notifications
You must be signed in to change notification settings - Fork 155
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 Artifactory #602
Comments
Also not sure if it makes sense to able to update the Repository in renv.lock to be flagged as a "versioned-archives" Repository - then we could build the url properly based on the Repository settings |
That's correct; Lines 553 to 565 in d10f636
But we'd need to make this "cheap"; e.g. |
Is there a way to tell if a CRAN repository is an Artifactory repository (e.g. checking the headers or something from a web request)? |
I just hit both our base URL (the URL that is in the X-Artifactory-Id Here are the values for ours (sort of) X-Artifactory-Id: 601b67c93bea52ad53d8fbf7a2d69fed56e4dbe9 The Node-Id header may be only used if setup as a clustered application. That makes this super cheap - you can then know that a Repository has CRAN structure or Artifactory structure |
Awesome! For now, I've implemented something that should work as well -- |
I will but not until I return home after the first of the year |
@kevinushey I'm having trouble getting this tested - some of my initial tests had some issues so I wanted to start completely clean - however I'm on a system that is R 3.6.1 and cannot use usethis 2.0.0 because of the change from git2r to gert (libgit2). Here is what I'm doing
So I can't seem to init a clean project with a clean library. |
My earlier test (yesterday) was with 0.12.3-71 - not sure if I should try to install that instead? renv::upgrade always gives me an rdb corrupt file issue |
aha - looking at bootstrap.R I needed to set a GITHUB_PAT... |
Nuts - I need the RENV_PATHS_ROOT changed - not just cache... redoing this whole thing |
so all worked great on this - I'll upload the "script" that I used to test it tomorrow but no problems at all. |
here is my "memory" of what I did - again it all looks good to me
|
I think we can close this issue - thank you @kevinushey |
Awesome. Thanks! For reference, here's where the "magic" happens: Lines 576 to 621 in 05028b9
Basically, we try both archive paths; if one of those succeeds, then we "save" that as the preferred path to use when attempting to install packages from the archives. |
@kevinushey thanks - I found it by looking through the git diff as well One thing to be aware of with Artifactory. In it you can define virtual repositories that are the combination of remote repositories (basically a true CRAN mirror - but with the ability to accept-list / deny-list various packages) and a local repository (for non-public packages). The remote repo will have the structure of the repository that it is mirroring - the local repo will have the structure defined by Artifactory. I don't think that this will be a problem as renv always looks at the CRAN repo first (that being mirrored) and thus should only use the Artifactory / local repo when the package is not found / not public (this is my case). There may be users that have to use both the remote and local parts of Artifactory but that is probably quite rare. I don't think the code needs changing - just wanted to make sure you understood what might be there in the Artifactory world |
There is a similar issue logged for packrat as well - rstudio/packrat#583
Artifactory does not store archived versions in a CRAN-like way - see
The last issue from Artifactory looks like they have changed this in their code but I'm not clear on what version this fix is included in.
I thought about re-implementing this PR from remotes - r-lib/remotes#441 - thinking that will also fix renv but now I don't believe that that is true (since renv only Suggests remotes)
Am I correct in reading the code that install.R eventually calls r_cmd_install on packages?
And the code that works out the correct location of the package is in retreive.R?
Not sure if it makes sense to change renv_retrieve_repos_archive to also try with
repo <- file.path(repo, "src/contrib/Archive", record$Package, record$Version)
or if renv_retrieve_repos_impl should do the test - this is only broken for Archive'd versions...
But am I correct in assuming that a fix to remotes won't do anything for renv?
The text was updated successfully, but these errors were encountered: