Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`methods` not loaded/working when using lubridate::object notation in Rscript #407

Closed
mmuurr opened this issue Apr 28, 2016 · 2 comments
Closed

Comments

@mmuurr
Copy link

@mmuurr mmuurr commented Apr 28, 2016

I'm having some trouble executing functions that rely on package methods when being run via Rscript. I already know that methods is not attached via Rscript, but it should be loaded (and usable) by the dependent packages and accessible via their package namespaces, at least I thought so...

Example R script (executed via Rscript):

#!/usr/bin/Rscript

sessionInfo()

tryCatch({
    str(lubridate::days(30))
}, error = function(e) {
    print(e)
})

sessionInfo()

tryCatch({
    str(lubridate::days(30))
}, error = function(e) {
    print(e)
})

library(methods)
str(lubridate::days(30))
sessionInfo()

Output, with my comments and questions mixed below ...

First, here's the startup sessionInfo():

# sessionInfo()

R version 3.2.2 (2015-08-14)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Amazon Linux AMI 2015.09

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  base

As expected with Rscript, package methods is not attached, nor loaded.

Now, what's surprising to me is that I thought the lubridate::days(30) call would load methods, since the lubridate package does "Depend" on methods, as verified in lubridate's DESCRIPTION file. Instead, I get the error:

# tryCatch({
#     str(lubridate::days(30))
# }, error = function(e) {
#     print(e)
# })

<simpleError in .setupMethodsTables(fdef, initialize = TRUE): trying to get slot "group" from an object of a basic class ("NULL") with no slots>

But now I'm really confused, because methods does seem to have been loaded, as seen with the next sessionInfo() call:

# sessionInfo()  

R version 3.2.2 (2015-08-14)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Amazon Linux AMI 2015.09

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  base

loaded via a namespace (and not attached):
[1] magrittr_1.5         tools_3.2.2          lubridate_1.5.6.9000
[4] stringi_1.0-1        methods_3.2.2        stringr_1.0.0

Just to be sure (about my confusion), let's try calling lubridate::days(30) again:

# tryCatch({
#     str(lubridate::days(30))
# }, error = function(e) {
#     print(e)
# })

<simpleError in .setupMethodsTables(fdef, initialize = TRUE): trying to get slot "group" from an object of a basic class ("NULL") with no slots>

Same error.

OK, now let's explicitly attach methods and try the lubridate::days(30) call again:

# library(methods)
# str(lubridate::days(30))

Formal class 'Period' [package "lubridate"] with 6 slots
  ..@ .Data : num 0
  ..@ year  : num 0
  ..@ month : num 0
  ..@ day   : num 30
  ..@ hour  : num 0
  ..@ minute: num 0

That worked!
What changed by specifically attaching methods?:

# sessionInfo()

R version 3.2.2 (2015-08-14)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Amazon Linux AMI 2015.09

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] methods   stats     graphics  grDevices utils     datasets  base

loaded via a namespace (and not attached):
[1] magrittr_1.5         tools_3.2.2          lubridate_1.5.6.9000
[4] stringi_1.0-1        stringr_1.0.0

methods is not attached (as opposed to loaded-but-not-attached).

I know I could solve all the headaches by simply including library(methods) atop scripts, but this seems silly, as I thought loading methods would have the same affect to the underlying packages (due to R's package namespacing), without me having to know specifically if any package I use relies on methods or not.

Does this seem like an R problem, or possibly a namespace issue with lubridate?

@vspinu
Copy link
Member

@vspinu vspinu commented Apr 29, 2016

methods namespace is special somehow. You can also solve it by library(lubridate). Not much we can do at lubridate side. methods is already listed as our dependency. This is a duplicate of #314.

@shrektan
Copy link
Contributor

@shrektan shrektan commented Apr 29, 2016

Its how rscript works and there's little to do with lubridate. Either explicitly attach methods in your script or make a pull request that is adding method in the import of the description file ~ I guess.

@vspinu vspinu closed this Apr 29, 2016
infotroph added a commit to infotroph/lubridate that referenced this issue Oct 4, 2017
infotroph added a commit to infotroph/lubridate that referenced this issue Oct 6, 2017
infotroph added a commit to infotroph/lubridate that referenced this issue Oct 6, 2017
infotroph added a commit to infotroph/lubridate that referenced this issue Oct 6, 2017
vspinu added a commit that referenced this issue Oct 8, 2017
[#407, #499] Import from methods
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants