pkg_install() doesn't respect download options

[kenahoo]

At my organization, we have a local CRAN-alike that requires authentication for access. Using the core R tools, I can set the following options to let curl handle the authentication:

options(download.file.method = 'curl', download.file.extra = '--netrc')

The benefit of doing things this way is that the username & password stay out of the text of the URL, so they don't appear in log files, etc.

With pak::pkg_install() though, the standard download.file mechanism doesn't seem to be used, and I don't see another way to pass credentials for download:

> options(repos=c(Local = "https://example.com/myrepository/",
                  CRAN = "https://cran.revolutionanalytics.com")
> pak::pkg_install('mboost')
ℹ Checking for package metadata updates
✖ Metadata download failed                                                                            
Error in stop(http_error(resp)) : Unauthorized (HTTP 401).                                            

There are actually 2 issues here:

1. The HTTP 401 failure to supply credentials for the first entry in options('repos')
2. The failure to keep trying the next site in options('repos') - mboost is a normal CRAN package, it wouldn't have been found at the first URL anyway.

A current workaround would be to use download.file and then install from the tarball directly. Could support for these options be added, either by leveraging download.file (preferred) or aping its behavior?

(This ticket is similar to r-lib/remotes#290 where I used to have the same issue with remotes::install_url().)

[kenahoo]

A note on the workaround: it wouldn't work very well if some dependencies also need to be pulled from the private repo, that would result in a lot of manual dependency-chasing, which I suspect wouldn't cooperate very well with pak's dependency solver, so that's ultimately kind of a no-go.

[hadley]

I don't think using download.file() is feasible, but we can provide some standard way to pass options onto curl.

[kenahoo]

Any update here? I still can't seem to use pak to download anything from a password-protected repo, even if I stuff the username & password into the URL using https://user:[email protected]/myrepository.

[kenahoo]

Is there any movement on this? It's a blocker for me being able to use pak. Let me know if there's something I can do to help.

[kenahoo]

I am still hoping for this, please provide an update if possible.

[gaborcsardi]

I am not sure if pak is mangling the password out of the URL, I would think not. Does download.file() work on your https://user:[email protected]/myrepository repo directly? E.g. can you run

download.file("https://user:[email protected]/myrepository/src/contrib/PACKAGES", tempfile())

Does this work?

curl::curl_download("https://user:[email protected]/myrepository/src/contrib/PACKAGES", tempfile())

[kenahoo]

Hi Gabor, thanks for the response. We're not putting the username & password directly in the URL, you can see the details in my original question. We're using curl's --netrc flag, which knows to pull the credentials from ~/.netrc.

The reason we strongly prefer this is that it keeps the credentials from appearing in log files, etc.

[kenahoo]

Hello from 4 years in the future. =)

I am still very interested in getting pak to support reading credentials from a .netrc file instead of needing to embed them in the URL.

[hadley]

@kenahoo the good news is that I've heard this request from more folks, so I think we are likely to provide some tooling for passing usernames and passwords to CRAN-like repos. (Probably not via a netrc file but hopefully something almost as convenient)