problem setting globals in .onLoad() about devtools HOT 11 CLOSED

The problem is that I have no control over <<- - it's always going to work in the global environment, instead of the environment in which devtools is loading all the other code. Could you provide a bit more info about what you're doing with the globals? There might be a better way to set them up.

from devtools.

The code keeps a list of database environment variables and a key for
which to DB use. It's in the global environment since the package is
also used in some legacy code which sets these explicitly prior to the
package being loaded.

Here is the actual .onLoad function....

.onLoad <- function(lib, pkg, ...) {
  ## CONNECTION MANAGEMENT
  if (!exists(".DB.USE",globalenv()))
    .DB.USE <<- Sys.getenv("DB_USE", unset="PROD")

  if (!exists(".DB.ENV",globalenv())) {
    .DB.ENV <<- list()
    .DB.ENV[[.DB.USE]] <<- db.env.get(.DB.USE)
  }
}

I changed it to use the package namespace (following the example in
lubridate):

.DB.ENV <- NULL
.DB.USE <- NULL

.onLoad <- function(lib, pkg, ...) {
  ## CONNECTION MANAGEMENT
  if (is.null(.DB.USE))
    .DB.USE <<- Sys.getenv("DB_USE",unset="PGPROD")

  if (is.null(.DB.ENV)) {
    .DB.ENV <<- list()
    .DB.ENV[[.DB.USE]] <<- db.env.get(.DB.USE)
  }
}

Which is cleaner, works, and is no doubt the right answer but that
means I needed to explicitly unlock the bindings for .DB.USE and
.DB.ENV, and the existing legacy code would need to be modified to
work properly (overdue cleanup so not terrible I guess).

It just surprised me that a package that worked fine via library would not load.
Looking at devtools code I am guessing the issue is that when you create
the environment you don't assign a parent frame and then do the attach
before sourcing the code rather than sourcing then attaching.

from devtools.

I accidentally closed this. I made the change to create the environment, source, then attach and then the sample code works. Take a look at jcdny/devtools@025c6504c1907e37accd for what I am talking about.

from devtools.

You've made two changes in that code - one to source then attach, and the other to use global environment as the parent. Would you mind testing to figure out which is the important change?

from devtools.

You need to do both things. You need to provide the enclosing environment when doing the source and when you attach it actually makes a copy of the environment and I think discards the enclosing environment.

I've messed around with it a bit and nothing seems to break with that change though I admit it was all a bit cargo culted and it's not clear if the env should be globalenv() or
something else. Someone with much more R internals experience would have to answer that one.

from devtools.

Here is a simple example of what I am talking about

In /tmp/x.R:
ZZ <<- 1
cat("found ZZ in",find("ZZ"),"\n")
cat("ZZ=",ZZ,"\n")

then run:

e1 <- new.env(parent = emptyenv())
attach(e1, name="E1")
e2 <- as.environment("E1")
e3 <- new.env(parent = globalenv())
attach(e3, name="E3")
e4 <- as.environment("E3")


for (e in c("e1","e2","e3","e4")) {
  cat("\n",e,"\n")
  print(get(e))
  try(sys.source("/tmp/x.R", env=get(e)))
  try(rm("ZZ", envir=globalenv()))
}

Which for me produced:
e1
<environment: 0x2873178>
Error in eval(expr, envir, enclos) : could not find function "<<-"

 e2 
<environment: 0x28728a0>
attr(,"name")
[1] "E1"
found ZZ in .GlobalEnv 
Error in cat("ZZ=", ZZ, "\n") : object 'ZZ' not found
In addition: Warning message:
In rm("ZZ", envir = globalenv()) : object 'ZZ' not found

 e3 
<environment: 0x1fc4160>
found ZZ in .GlobalEnv 
ZZ= 1 

 e4 
<environment: 0x1fc38f8>
attr(,"name")
[1] "E3"
found ZZ in .GlobalEnv 
Error in cat("ZZ=", ZZ, "\n") : object 'ZZ' not found

from devtools.

Thanks Jeff - I'll incorporate that change when I get a chance

from devtools.

Hmmmm, this change breaks with S4 because of the way method tables work - the environment needs to be attached before the class definition functions are run,

from devtools.

Ah, I tested with a number of packages but nothing with S4 methods. That's unfortunate.

I will think about it more and if I get any bright ideas I will let you know. I suspect to support namespaces you will need to load packages more like the existing code does and that might be the only way to get both of these.

from devtools.

Yes, it's hard to replicate regular package loading exactly because so many of the key functions are internal, and nothing is really documented. One day I'll be able to do better!

from devtools.

Fixed in #126.

from devtools.