How to switch to a new environment and insert it into it?

Question

I am creating an analysis workflow for large data sets, but first I have to test it on smaller data sets. What I would like to do is to separate my “selective” data sets from the actual data sets, putting them in such an environment:

sample_data<-new.env() attach(sample_data) # downloading sample_data sets sample_df_1 <- some_download_function(parameters1) sample_df_2 <- some_download_function(parameters2) ... # doing some stuff with them ... 

However, when I do this, sample_df_1 and sample_df_2 will be saved in the global environment, not in my sample_data environment. Of course, I can use assign(..., envir=sample_data) , but this is somewhat tedious, and I do not want them to appear in the final code.

It is also not recommended to use with , because the lines of code inside it cannot be executed one after another, which makes it rather inconvenient at the development stage.

I hope to achieve the same behavior as debug and undebug , for example:

 switch_to_env(sample_data) # Everything done here will be done within environment "sample_data" # And the lines of codes here can be executed one by one switch_to_env(.GlobalEnv) 

as @Gregor noted, “setting an option” probably better describes what I'm looking for: a parameter that allows the user to specify the environment in which the R REPL evaluates expressions.

Thanks!

Answer 1

This is not exactly what you are looking for, but I find it workable (and safe).

Whenever you want to work in a new environment, open a new file and a new R session (say, sample_data.R ), source() a script that creates any objects you want in the parent environment, and do your development as usual .

If you want to access them in a specific environment from your real global environment, you can do this (in the original session / R environment)

 sample_data<-new.env() source("sample_data.R", local = sample_data) 

It has some disadvantages: it is very inconvenient for switching back and forth frequently, especially if your code takes a long time to run. However, I really like the fact that it makes separate code for different arguments into different files - it sounds like a potentially buggy system if you mix where and in what environment you work. Having separate files provides some protection by providing code separation. It also makes your various sub-environments easily skip from the run --- commenting out the source() in your main file disables the entire sub-environment.

Answer 2

You can assign variables to the new environment as follows:

 sample_data<-new.env() sample_data$sample_df_1 <- some_download_function(parameters1) sample_data$sample_df_2 <- some_download_function(parameters2) 

You can then access these variables in the new environment, either by binding the environment like you, or using sample_data$sample_df_1

Is that what you mean?