Using pak behind a firewall

[etiennebr]

When using pak behind a firewall, I get an error:

pak::pkg_install("dplyr")
#> Error: callr subprocess failed: cannot open URL 'http://bioconductor.org/config.yaml'

This is completely normal because we have a redirect to an internal CRAN mirror, but no BioC mirror (and bioconductor.org is blocked). However, the package is available form CRAN, so I was looking for a way to either skip BioC if the package is available form CRAN, or specify the list of servers to probe. It doesn't seem that pak uses the repos option.

[gaborcsardi]

We should have a config option for ignoring BioC packages.

[wurli]

Any update on this? I'm running into the same issue.

[gaborcsardi]

@wurli You mean disabling Bioconductor? You can indeed do that now with

options(use_bioconductor = FALSE)

or setting the corresponding env var. See https://pak.r-lib.org/reference/pak-config.html

[wurli]

Thank you! I saw that in the documentation but it doesn't seem to be completely stopping pak from trying to query Bioconductor when making the installation plan:

options(use_bioconductor = FALSE)
options(pkg.use_bioconductor = FALSE)
Sys.setenv(PKG_USE_BIOCONDUCTOR = "FALSE")

pak::pak("DBI")
#> Error: ! error in pak subprocess
#> Caused by error in `download.file(url, tmp, quiet = TRUE)`:
#> ! cannot open URL 'http://bioconductor.org/config.yaml'

^{Created on 2024-06-19 with reprex v2.1.0}

Here's the full .Last.error traceback:

<callr_error/rlib_error_3_0/rlib_error/error>
Error:
! error in pak subprocess
Caused by error in `download.file(url, tmp, quiet = TRUE)`:
! cannot open URL 'http://bioconductor.org/config.yaml'
---
Backtrace:
1. pak::pak("DBI")
2. pak::pkg_install(pkg, ...)
3. pak:::remote(function(...) get("pkg_install_make_plan", asNamespace("pak"))(...), …
4. err$throw(res$error)
---
Subprocess backtrace:
 1. base::withCallingHandlers(cli_message = function(msg) { …
 2. get("pkg_install_make_plan", asNamespace("pak"))(...)
 3. pkgdepends::new_pkg_installation_proposal(pkg, config = list(library = lib, …
 4. pkg_installation_proposal$new(refs, config = config, ...)
 5. local initialize(...)
 6. pkg_plan$new(refs, config = config, library = config$library, …
 7. local initialize(...)
 8. pkgdepends:::pkgplan_init(self, private, refs, config, library, remote_types, …
 9. pkgcache::cranlike_metadata_cache$new(replica_path = private$config$get("metadata_cache_dir"), …
10. local initialize(...)
11. pkgcache:::cmc_init(self, private, primary_path, replica_path, platforms, …
12. pkgcache:::cmc__get_repos(repos, bioc, cran_mirror, r_version)
13. bioconductor$get_repos()
14. local get_bioc_version(getRversion(), forget)
15. local get_matching_bioc_version(r_version, forget = forget)
16. local get_version_map(forget = forget)
17. local get_yaml_config(forget)
18. base::stop(new)
19. global (function (e) …

[gaborcsardi]

Right, that seems like a bug indeed.

[meztez]

Would it be an option to modifiy:

meta_summary_internal <- function() {
  cmc <- pkgcache::cranlike_metadata_cache$new(
    platforms = pkgdepends::current_config()$get("platforms"),
    cran_mirror = pkgdepends::current_config()$get("cran_mirror"),
    r_version = pkgdepends::current_config()$get("r_versions")
  )

meta_summary_internal <- function() {
  cmc <- pkgcache::cranlike_metadata_cache$new(
    platforms = pkgdepends::current_config()$get("platforms"),
    cran_mirror = pkgdepends::current_config()$get("cran_mirror"),
    r_version = pkgdepends::current_config()$get("r_versions"),
    bioc = pkgdepends::current_config()$get("use_bioconductor")
  )

and the other cranlike_metadata_cache$new

in https://github.com/r-lib/pak/blob/main/R/cache.R

[gaborcsardi]

@meztez Yes, that seems right.

[scm-dan]

I have the same issue. Please expedite this PR and merge it in order to fix this. @meztez @gaborcsardi @m-muecke

#696

[meztez]

@scm-dan You can workaround it.

config.yaml.txt

ADD files/config.yaml /src/config.yaml
ENV R_BIOC_CONFIG_URL=file:///src/config.yaml
ENV PKG_USE_BIOCONDUCTOR=FALSE

[alejandrohagan]

Hi, do I understand that a fix is coming or should we reference the work around instead?