Helllo, Thanks for the info. I still think these variables should not be loaded when library(spdep) is called. But I'll handle it following your suggestion. Thanks, Jeremie> It turns out that that 'x' comes from the spData package and lives > inside that package (part of its namespace). > >> spData::x > [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 > > This is conceptually no different from other objects in package > namespace, although we are more used to seeing functions and not data > object. Another well-known example of this is: > >> base::pi > [1] 3.141593 > > So, this 'x' is *not* in your global workspace and you cannot remove > it without unloading the package. > > /Henrik>> >> >> I found a dangerous issue in the library spdep. I get variables x and y >> that cannot be removed by rm() and I don't don't how they show up. Can >> anyone reproduce this? >> >> ~$ R --vanilla >> > rm(list=ls()) >> > library(spdep) >> > x >> [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 >> > rm(list=ls()) >> > x >> [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 >> >> >> >> > Sys.info() >> >> sysname "Linux" >> release "4.9.0-6-amd64" >> version "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)" >> nodename "freegnu" >> machine "x86_64" >> >> >> > Session >> >> >> > sessionInfo() >> >> R version 3.4.1 (2017-06-30) >> Platform: x86_64-pc-linux-gnu (64-bit) >> Running under: Debian GNU/Linux 9 (stretch) >> >> Matrix products: default >> BLAS: /usr/local/lib/R/lib/libRblas.so >> LAPACK: /usr/local/lib/R/lib/libRlapack.so >> >> locale: >> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> loaded via a namespace (and not attached): >> [1] compiler_3.4.1 >> >> ______________________________________________ >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code.
This is intended/expected because the spdep package *depends* on the spData package (see https://cran.r-project.org/web/packages/spdep/), which means that the maintainer of spdep intends also spData to be *attached* whenever spdep is attached. If they would have only imported it, then spData would only be *loaded* (but not attached), and you would not get 'spData' on your search() path and therefore not see 'x' either. Example: ## Loading spData> loadNamespace("spData")<environment: namespace:spData>> loadedNamespaces()[1] "compiler" "graphics" "utils" "grDevices" "stats" "datasets" [7] "methods" "spData" "base" ## The search path used to find objects> search()[1] ".GlobalEnv" "package:stats" "package:graphics" [4] "package:grDevices" "package:utils" "package:datasets" [7] "package:methods" "Autoloads" "package:base" ## So, spData::x is not found> xError: object 'x' not found ## But is still there> spData::x[1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 ## Attaching spData, which also happens when you do library(spdat)> library(spData)To access larger datasets in this package, install the spDataLarge package with: `install.packages('spDataLarge', repos='https://nowosad.github.io/drat/', type='source'))> loadedNamespaces()[1] "compiler" "graphics" "utils" "grDevices" "stats" "datasets" [7] "methods" "spData" "base" ## Now, spData is on the search path> search()[1] ".GlobalEnv" "package:spData" "package:stats" [4] "package:graphics" "package:grDevices" "package:utils" [7] "package:datasets" "package:methods" "Autoloads" [10] "package:base> x[1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450> find("x")[1] "package:spData" /Henrik On Mon, Jul 23, 2018 at 2:01 PM Jeremie Juste <jeremiejuste at gmail.com> wrote:> > > Helllo, > > Thanks for the info. I still think these variables should not be loaded > when library(spdep) is called. > > But I'll handle it following your suggestion. > > Thanks, > > Jeremie > > > > > > > > It turns out that that 'x' comes from the spData package and lives > > inside that package (part of its namespace). > > > >> spData::x > > [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 > > > > This is conceptually no different from other objects in package > > namespace, although we are more used to seeing functions and not data > > object. Another well-known example of this is: > > > >> base::pi > > [1] 3.141593 > > > > So, this 'x' is *not* in your global workspace and you cannot remove > > it without unloading the package. > > > > /Henrik > > > >> > >> > >> I found a dangerous issue in the library spdep. I get variables x and y > >> that cannot be removed by rm() and I don't don't how they show up. Can > >> anyone reproduce this? > >> > >> ~$ R --vanilla > >> > rm(list=ls()) > >> > library(spdep) > >> > x > >> [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 > >> > rm(list=ls()) > >> > x > >> [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 > >> > >> > >> > >> > Sys.info() > >> > >> sysname "Linux" > >> release "4.9.0-6-amd64" > >> version "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)" > >> nodename "freegnu" > >> machine "x86_64" > >> > >> > >> > Session > >> > >> > >> > sessionInfo() > >> > >> R version 3.4.1 (2017-06-30) > >> Platform: x86_64-pc-linux-gnu (64-bit) > >> Running under: Debian GNU/Linux 9 (stretch) > >> > >> Matrix products: default > >> BLAS: /usr/local/lib/R/lib/libRblas.so > >> LAPACK: /usr/local/lib/R/lib/libRlapack.so > >> > >> locale: > >> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > >> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 > >> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 > >> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > >> [9] LC_ADDRESS=C LC_TELEPHONE=C > >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C > >> > >> attached base packages: > >> [1] stats graphics grDevices utils datasets methods base > >> > >> loaded via a namespace (and not attached): > >> [1] compiler_3.4.1 > >> > >> ______________________________________________ > >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > >> https://stat.ethz.ch/mailman/listinfo/r-help > >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > >> and provide commented, minimal, self-contained, reproducible code.
Many thanks for the info. I see the point but I'll think calling the spData would be a cheaper price to pay. If each package one load provide access to their variables things are likely to get messy. I guess many R users would like to control the variables in their global environment. And since it is not trival to protect variables inside a function from the parent environment this is potentially dangerous. Best wishes, Jeremie Henrik Bengtsson <henrik.bengtsson at gmail.com> writes:> This is intended/expected because the spdep package *depends* on the > spData package (see https://cran.r-project.org/web/packages/spdep/), > which means that the maintainer of spdep intends also spData to be > *attached* whenever spdep is attached. If they would have only > imported it, then spData would only be *loaded* (but not attached), > and you would not get 'spData' on your search() path and therefore not > see 'x' either. > > Example: > > ## Loading spData >> loadNamespace("spData") > <environment: namespace:spData> > >> loadedNamespaces() > [1] "compiler" "graphics" "utils" "grDevices" "stats" "datasets" > [7] "methods" "spData" "base" > > ## The search path used to find objects >> search() > [1] ".GlobalEnv" "package:stats" "package:graphics" > [4] "package:grDevices" "package:utils" "package:datasets" > [7] "package:methods" "Autoloads" "package:base" > > ## So, spData::x is not found >> x > Error: object 'x' not found > > ## But is still there >> spData::x > [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 > > ## Attaching spData, which also happens when you do library(spdat) >> library(spData) > To access larger datasets in this package, install the spDataLarge > package with: `install.packages('spDataLarge', > repos='https://nowosad.github.io/drat/', type='source')) > >> loadedNamespaces() > [1] "compiler" "graphics" "utils" "grDevices" "stats" "datasets" > [7] "methods" "spData" "base" > > ## Now, spData is on the search path >> search() > [1] ".GlobalEnv" "package:spData" "package:stats" > [4] "package:graphics" "package:grDevices" "package:utils" > [7] "package:datasets" "package:methods" "Autoloads" > [10] "package:base > >> x > [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 > >> find("x") > [1] "package:spData" > > /Henrik > On Mon, Jul 23, 2018 at 2:01 PM Jeremie Juste <jeremiejuste at gmail.com> wrote: >> >> >> Helllo, >> >> Thanks for the info. I still think these variables should not be loaded >> when library(spdep) is called. >> >> But I'll handle it following your suggestion. >> >> Thanks, >> >> Jeremie >> >> >> >> >> >> >> > It turns out that that 'x' comes from the spData package and lives >> > inside that package (part of its namespace). >> > >> >> spData::x >> > [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 >> > >> > This is conceptually no different from other objects in package >> > namespace, although we are more used to seeing functions and not data >> > object. Another well-known example of this is: >> > >> >> base::pi >> > [1] 3.141593 >> > >> > So, this 'x' is *not* in your global workspace and you cannot remove >> > it without unloading the package. >> > >> > /Henrik >> >> >> >> >> >> >> >> I found a dangerous issue in the library spdep. I get variables x and y >> >> that cannot be removed by rm() and I don't don't how they show up. Can >> >> anyone reproduce this? >> >> >> >> ~$ R --vanilla >> >> > rm(list=ls()) >> >> > library(spdep) >> >> > x >> >> [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 >> >> > rm(list=ls()) >> >> > x >> >> [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 >> >> >> >> >> >> >> >> > Sys.info() >> >> >> >> sysname "Linux" >> >> release "4.9.0-6-amd64" >> >> version "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)" >> >> nodename "freegnu" >> >> machine "x86_64" >> >> >> >> >> >> > Session >> >> >> >> >> >> > sessionInfo() >> >> >> >> R version 3.4.1 (2017-06-30) >> >> Platform: x86_64-pc-linux-gnu (64-bit) >> >> Running under: Debian GNU/Linux 9 (stretch) >> >> >> >> Matrix products: default >> >> BLAS: /usr/local/lib/R/lib/libRblas.so >> >> LAPACK: /usr/local/lib/R/lib/libRlapack.so >> >> >> >> locale: >> >> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >> >> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >> >> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >> >> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >> >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >> >> >> >> attached base packages: >> >> [1] stats graphics grDevices utils datasets methods base >> >> >> >> loaded via a namespace (and not attached): >> >> [1] compiler_3.4.1 >> >> >> >> ______________________________________________ >> >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> >> https://stat.ethz.ch/mailman/listinfo/r-help >> >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html >> >> and provide commented, minimal, self-contained, reproducible code.