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.bengts...@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 <jeremieju...@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@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. ______________________________________________ R-help@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.