5

If you have a fresh R session (no packages attached except those from base) and try to create the following xts object ordered by a yearmon class...

df <- data.frame(date = zoo::as.yearmon(seq.Date(as.Date("2015-01-01"),
                                                 as.Date("2015-12-31"),
                                                 by = "month")),
                 num = rnorm(12, 0, 1))

dates <- df[,1]

xts::xts(as.matrix(df[, -1]), order.by = dates)

you get the following error.

enter image description here

I thought I understood the R namespace framework, but in this case I'm completely lost. Why is that xts tries to call the as.yearmon function when the dates object is already a yearmon object? I am aware that xts depends on zoo but is that the reason?

If zoo is attached then of course the error goes away.

The reason why I am interested in this issue is that I am creating a package that uses the xts package. One of my functions return a xts object, but I would like my package to only depend on R and import all the other packages - which is described as best practice by Hadley Wickham (as I understand it). However, because of this issue I need to depend the zoo package to make this work.

I'm sure that I'm overlooking something, so I hope a friendly soul here at SO can help explain this issue and present a solution. Thanks!

P. Garnry
  • 344
  • 1
  • 6
  • 12
  • 3
    The problem is that **xts** "Depends" on rather than "Imports" the **zoo** package. Unless you can convince the authors of **xts** to import **zoo** (and -- given that they are both very experienced R programmers -- they may have good reasons not to have done so), you'll need your package to also Depend on **zoo**. ([See here](http://stackoverflow.com/questions/8637993/better-explanation-of-when-to-use-imports-depends/8638902#8638902) for some more explanation/discussion of this issue.) – Josh O'Brien Jan 02 '16 at 21:14
  • Thanks Josh! And great answer on depends vs imports - just upvoted it. You confirmed my own thinking on the xts issue. Yes, Jeffrey and Joshua are very experienced so there is probably a very good reason. I'm just very curious to know why. As I have understood Hadley there is really no reason to use depends. The downside of imports, despite it is a better "citizen" as you say, is that it be quite cumbersome to write :: all over your code. Especially if you use the same function many times. But here it would still be better to then do an import from statement in order to avoid the :: right? – P. Garnry Jan 02 '16 at 21:32
  • Oh heck. It's an answer that I already upvoted so no more rep for you, J.O'B. – IRTFM Jan 02 '16 at 22:13

2 Answers2

3

This is an issue with the current version of xts on CRAN. It has been fixed in the development version of xts on GitHub. The problem was that all the zoo functions xts used internally were not imported in the NAMESPACE.

R> df <- data.frame(date = zoo::as.yearmon(seq.Date(as.Date("2015-01-01"),
+                                                  as.Date("2015-12-31"),
+                                                  by = "month")),
+                  num = rnorm(12, 0, 1))
R> 
R> dates <- df[,1]
R> 
R> xts::xts(as.matrix(df[, -1]), order.by = dates)
               [,1]
Jan 2015 -1.2141571
Feb 2015 -0.7645339
Mar 2015 -0.7555164
Apr 2015 -0.6596672
May 2015  0.2099139
Jun 2015 -0.3374191
Jul 2015  1.1704935
Aug 2015 -2.2101577
Sep 2015  0.7623118
Oct 2015  0.3643535
Nov 2015 -1.2789485
Dec 2015  1.0316663
R> search()
[1] ".GlobalEnv"        "package:stats"     "package:graphics" 
[4] "package:grDevices" "package:utils"     "package:datasets" 
[7] "package:methods"   "Autoloads"         "package:base"     
R> packageVersion('xts')
[1] ‘0.9.8’
Joshua Ulrich
  • 173,410
  • 32
  • 338
  • 418
  • Thanks for your quick answer Joshua - looks good. Do you have an approximate ETA on when the GitHub development version will be merged into master and pushed to CRAN for approval? – P. Garnry Jan 03 '16 at 15:10
  • @P.Garnry: I'm not sure when it will be on CRAN because it contains breaking changes to `plot.xts`. I need to work with other package maintainers to do a coordinated update. And to clarify, the development of xts on GitHub happens on the master branch, so there's no need to merge. – Joshua Ulrich Jan 03 '16 at 15:17
  • Cool. Just to be 100% sure, so if I clone the current xts repository (master) it will be the version with zoo imported into namespace? Looking forward to have it on CRAN later...and good work on xts. I believe it is the best choice for R users working with time series objects. – P. Garnry Jan 03 '16 at 15:29
  • @P.Garnry: Yes, the HEAD of master in the xts repo has the fix that I used for my answer. – Joshua Ulrich Jan 03 '16 at 16:58
1

With the update to xts version 0.10 on CRAN this is no longer an issue

Chitown
  • 41
  • 7