devtools::load_all() may fail when S4 class definitions are in different files #623
If I create a simple example project and add two files in the R directory as follows
#' @include b.r Class2 <- setClass('Class2',contains='Class1')
and b.r is
then when I try to run load_all() on this package I get the following error messages
The problem arises because although I have the @include directive in my file a.r, it has not yet been processed, so load_all() attempts to read the code from the files in alphabetical order.
I still get an error if I try and run devtools::document('.'), as seen here
And because of the error while loading, the document('.') does not finish, and does not update the collate entry in the package DESCRIPTION file.
A solution is to run roxygen2::update_collate() before trying to load_all() or document() my package
The updated collate entry in the DESCRIPTION file created by roxygen2::update_collate tells load_all() (and all the other devtools machinery) the correct order to process the files in.
I can avoid this problem myself now I know what causes it, but as an absolute novice package creator it really confused me for ages. In my real life example the alphabetic order of the file names was not so obvious, and when I tried to pin the error down by commenting out bits of code, it enabled devtools::document to run successfully. Then when I removed the commenting out, the original code would behave nicely, making the problem appear only intermittently and very frustratingly. It would be nice if some fix of the type I have illustrated could be included in the official devtools.
PS I'm still pretty much a novice package creator (waiting keenly for the book to be finished and published), just a little more informed about this particular problem.
PPS Because roxygen2::update_collate emits a message when it runs, I think simply adding a call to roxygen2::update_collate into the code for load_all may cause some of the testthat tests on devtools to fail (because they are not expecting that particular message to be there)
PPPS I have tried to write a testhat for devtools to check that the collate order is correct and up to date. The testthat code is
It requires a template project (which I have called testCollateOrder) with a plain vanilla DESCRIPTION file
The key feature is that there is no collate entry in the file yet.
The two files in the R directory are
The test will succeed if the @include directive has been recognised so that a.r is read after b.r
The text was updated successfully, but these errors were encountered:
PPPPS The sessionInfo for the examples was
I have just now updated from roxygen2 4.0.1 to 4.0.2 (the CRAN version of roxygen2, not the very latest github version) and I still get the same problem (as long as I remember to clean out the DESCRIPTION file so it has no collate entry, so that the example test is valid - once I've run roxygen2::update_collate() once, everything is of course fixed in the DESCRIPTION file my example )
I didn't think of checking the latest version of roxygen2 at first (but I should have done) because it looks like the failure happens before roxygen2 is invoked - apologies for the oversight.
I hadn’t at the time I posted the issue, but I did as soon as I saw your question, and the short answer is, using the latest CRAN version of roxygen2 doesn’t fix the issue (I think the error occurs before roxygen2 is invoked).
PS I’ve posted the details on github – I’m still getting used to what github does with notifications and watching etc, so apologies in advance for the duplication if you already saw my response there
From: Winston Chang [mailto:firstname.lastname@example.org]
Have you tried updating to the most recent roxygen2?
Thanks Hadley. That's what I thought after I'd read through the load.r code. It seems to be on the same plane as creating a default DESCRIPTION file if none exits.
PS I couldn't quite figure out whether or not it was necessary to call
I've hit a snag, which means I've got some more thinking to do. If you have any guidance to offer, it would be most appreciated.
Edited in some thoughts about options (on Mon 11 Nov 2014) - see below
It seems that
That's good for my situation :-) (as I slowly build up the package I am working on, and tidy the functions into nice workable and maintainable code, I want the Collate entries to be changed to reflect my latest file structure.)
But if someone else has chosen to create their Collate entries by manually editing the DESCRIPTION file instead of using the
It may need a bit more work to figure out which situation applies and hence to guess what the user actually wants to do.
PS This has been a really good example for me to appreciate the value of the testthat approach to development. I figured this out only after I started to try and work out why some of the existing expectations in
Edited in - thoughts about possible approaches
I can think of three possible approaches, none feel really good. The last one (3b) seems the least worst to me.
3a. Find out about the existence of any
Any comments and better suggestions much appreciated, Geoff
I think there is a bug in the version of
If I have a test package with the following DESCRIPTION file
and then run roxygen2::update_collate() on it
the DESCRIPTION file becomes
i.e. the collate entry is removed rather than nothing happening (there are no
I'll file an issue for roxygen2 (after I check that I am using an up to date version of roxygen2)
Not sure if it is the correct protocol to comment on a closed issue but I'd like to reopen the issue / suggest an additional change.
It appears that as well as calling
The following extra line (after the commented explanation) does this
Sure, I’ll be happy to.
Will be later today (my time) before I get chance to make sure I’ve got everything neat and tidy
From: Hadley Wickham [mailto:email@example.com]
Can you please refile a pull request with that change and the tests?