是否可以在 R 中将 package 环境作为特定环境而不是全局环境的父级附加？

Question

I'm trying to create a toy R REPL written in R ( here's the source code). Ideally I'd like the REPL to run in an R terminal itself, but neither to interfere nor to depend on anything that has already been evaluated at the global environment. Unfortunately, I haven't been able to do come up with a solution to this problem yet. One of the main challenges I'm facing refers to how package environments are attached.

According to Hadley's Advanced R , packages attached by library() and require() become parents of the global environment. This implies, however, that if I attach a package inside my toy REPL it will become the parent of the global environment even I'm not running it on the global environment.

For example (please note that the R> prompt is the "normal" R terminal, and that >>>> is my REPL's "terminal"):

R> search()
#  [1] ".GlobalEnv"        "tools:rstudio"     "package:stats"    
#  [4] "package:graphics"  "package:grDevices" "package:utils"    
#  [7] "package:datasets"  "package:methods"   "Autoloads"        
# [10] "package:base"     
R> replr::replr(env = new.env()) # new.env() defaults to having global environment as a parent
>>>> library(gtfsio)
>>>> rlang::env_parents(last = emptyenv())
#  [[1]] $ <env: global>
#  [[2]] $ <env: package:gtfsio>
#  [[3]] $ <env: tools:rstudio>
#  [[4]] $ <env: package:stats>
#  [[5]] $ <env: package:graphics>
#  [[6]] $ <env: package:grDevices>
#  [[7]] $ <env: package:utils>
#  [[8]] $ <env: package:datasets>
#  [[9]] $ <env: package:methods>
# [[10]] $ <env: Autoloads>
# [[11]] $ <env: package:base>
# [[12]] $ <env: empty>
>>>> import_gtfs()
# Error: argument "path" is missing, with no default
>>>> q()
R> search()
#  [1] ".GlobalEnv"        "package:gtfsio"    "tools:rstudio"    
#  [4] "package:stats"     "package:graphics"  "package:grDevices"
#  [7] "package:utils"     "package:datasets"  "package:methods"  
# [10] "Autoloads"         "package:base"  

We can see that I could use the gtfsio ' import_gtfs() function (the path is missing, but you get the point), but the package was also attached to the "main" R terminal. If I try to use another environment as the parent to my new env, I won't even have access to the package's functions, because it won't be able to find them, since the package environment becomes the parent of the global environment, and not of my new environment:

Restarting R session...

R> search()
#  [1] ".GlobalEnv"        "tools:rstudio"     "package:stats"    
#  [4] "package:graphics"  "package:grDevices" "package:utils"    
#  [7] "package:datasets"  "package:methods"   "Autoloads"        
# [10] "package:base" 
R> replr::replr(env = new.env(parent = baseenv()))
>>>> library(gtfsio)
>>>> rlang::env_parents()
# [[1]] $ <env: package:base>
# [[2]] $ <env: empty>
>>>> import_gtfs()
# Error: could not find function "import_gtfs"
>>>> q()
R> search()
#  [1] ".GlobalEnv"        "package:gtfsio"    "tools:rstudio"    
#  [4] "package:stats"     "package:graphics"  "package:grDevices"
#  [7] "package:utils"     "package:datasets"  "package:methods"  
# [10] "Autoloads"         "package:base"     

So, is there any way of attaching package environments as parents of a custom environment, instead of the global environment? If there's not, is there any way to workaround this issue?

Cheers!

---

Edit:

Sorry, I should have given more details on how the REPL works.

Basically, I just read the user input using readline() , parse it as an expression and evaluate it in the specified environment. The code below should work for a simple demonstration:

simple_repl <- function(env = new.env()) {
    
  while (TRUE) {
    
    input <- readline(">>>> ")
    
    if (input == "q()") break
    
    expr <- parse(text = input)
    
    result <- withVisible(
      eval(expr, envir = env)
    )
      
    if (result$visible)
      print(result$value)
      
  }
    
}

The code I linked above to my GitHub is a bit more complex to handle some conditions, but still, this is the basic idea.

A library() call would then be evaluated as eval(expression(library(gtfsio)), envir = env) .

Answer 1

You have only one search path so there's no way to properly attach to another one.

You can still have a chain of parent environments though, we might redefine library in your repl_env to set up this chain

repl_env <- new.env()
with(repl_env, library <- function(package) {
  # fetch repl_env from the inside
  repl_env    <- parent.env(environment())
  # and its parent (.GlobalEnv the first time)
  parent_env <- parent.env(repl_env)
  # create a new env for our package and fill it
  pkg_env <- new.env()
  package <- deparse1(substitute(package))
  object_nms <- getNamespaceExports(package)
  objects    <- mget(object_nms, envir = asNamespace(package))
  list2env(objects, pkg_env)
  # stitch it above repl_env and below repl_env's parent
  parent.env(pkg_env) <- parent_env
  parent.env(repl_env) <- pkg_env
  # base::library returns the search path invisibly but here it woudn't make
  # sense so we just return NULL
  invisible(NULL)
})

simple_repl(repl_env)
>>>> x <- "hello"
>>>> y <- "world"
>>>> library(glue)
>>>> glue("{x} {y}")
#> hello world
>>>> 

# the {glue} package is not on the search path  
search()
#> [1] ".GlobalEnv"        "tools:rstudio"     "package:stats"     "package:graphics" 
#> [5] "package:grDevices" "package:utils"     "package:datasets"  "package:methods"  
#> [9] "Autoloads"         "package:base"  

Use repl_env <- new.env(parent = parent.env(.GlobalEnv)) as your first line if you don't want to have access to the global environment's objects.

It will never be 100% robust however, it was a fun exercise but think carefully before doing something serious with this.