Skip to content

How to create vignette.pdf for R-2.13.0?

16 messages · cstrato, Duncan Murdoch, Brian Ripley +3 more

#
Dear Duncan, dear Uwe,

Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a 
virtual machine, I have now done the following tests on all three 
architectures:

1, R CMD build xps:
This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as 
pdf-file. Thus R CMD build is ok.

2, R CMD check xps:
This does NOT build the vignettes as pdf-files on all three 
architectures. Or to be more precise, R-2.13.0 does no longer build the 
vignettes since with R-2.12.2 and earlier versions R did create the 
vignettes as pdf-files.

Thus the question is:
Why does R CMD check no longer create the vignettes?

Best regards
Christian
On 4/27/11 10:16 AM, Uwe Ligges wrote:
#
On 11-05-01 4:10 PM, cstrato wrote:
Probably the answer is simply "because it doesn't".  For a truly 
reliable check, you should build the package, then check the tar.gz 
file.  Anything else is, and always has been, an approximation.

Duncan Murdoch
#
On Sun, 1 May 2011, Duncan Murdoch wrote:

            
Actually, it does.  What earlier versions never did (despite 
'cstrato's repeated delusional claims earlier) was to create the 
vignettes *in <pkg>inst/doc*.  All of them re-created (by default) 
vignettes in a working directory.  The difference is that 2.13.0 
deletes that working directory if the test was successful, whereas 
earlier versions left the results somewhere in <pkg>.Rcheck (the 
'somewhere' has varied). However, earier versions of R CMD check 
sometimes failed when R CMD build succeeded

Using Animal (a small CRAN package with one vignette).

R 2.12.2 gave

* checking package vignettes in ?inst/doc? ... WARNING
Package vignettes without corresponding PDF:
/tmp/Animal/inst/doc/Animal.Rnw

and the vignette was re-created in Animal.Rcheck/inst/doc.

R 2.13.0 gives

* checking package vignettes in ?inst/doc? ... WARNING
Package vignette(s) without corresponding PDF:
    Animal.Rnw

   Non-ASCII package vignette(s) without specified encoding:
    Animal.Rnw

* checking running R code from vignettes ... OK
* checking re-building of vignettes ... OK

and the working directory was Animal.Rcheck/vign_test .

The main reason for cleaning up is that to mimic R CMD build the 
test has to make a complete copy of the package sources, and that adds 
up: checking CRAN already takes 17GB for each flavour.

  
    
#
Dear Prof. Ripley,

Thank you for your confirmation and explanation, I understand the reason 
for cleaning things up to save memory. However, it was very convenient 
to have this feature in earlier versions of R. It would be really 
helpful to have an additional option to R CMD check, e.g. 
"--no-clean-vignettes".

FYI, I did not claim "..create the vignettes *in <pkg>inst/doc*", 
instead my words were:
One interesting observation is that xps.Rcheck from R-2.12.2 contains 
the subdirectory "inst/doc" with the vignettes while xps.Rcheck from 
R-2.13.0 does not contain "inst".

Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n   S.t.r.a.t.o.w.a
V.i.e.n.n.a           A.u.s.t.r.i.a
e.m.a.i.l:        cstrato at aon.at
_._._._._._._._._._._._._._._._._._
On 5/2/11 7:08 AM, Prof Brian Ripley wrote:
#
On 02.05.2011 21:24, cstrato wrote:
But you do not need it. I do not know how often I have to mention that 
vignettes are produced by R CMD build! They are already build when 
running R CMD check. And please do not tell us about tzhe PDF version 
oif manuals which are *unrelated* to vignettes, because they are not 
built in advance and need to be checked, since they should be produced 
at user level while vignettes are built at developer level already.

Uwe Ligges
#
Dear Uwe,

This is my development cycle:

First, I run R CMD check until there are no more warnings/errors. Since 
years it was very convenient that R CMD check builds the pdf-files of 
the vignettes, too, since this allowed me to correct errors in the 
manual files and the vignette files at the same time!

Afterwards I run R CMD INSTALL to install my package and do more tests 
until everything works.

As you see I do not use R CMD build, since every run takes about 5 
minutes, it overwrites my zipped source code, and I would need to unzip 
it to get access to the vignette pdf-files.

Best regards
Christian
On 5/3/11 1:07 PM, Uwe Ligges wrote:
#
On 03.05.2011 21:14, cstrato wrote:
Then this is the main problem here. The *recommended* development cycle 
from the manuals is to run

1. R CMD build in order to get a valid source tarball and clean the sources
2. R CMD INSTALL to check if your package can be installed
3. R CMD check in order to finally check your package

Running R CMD INSTALL on your source directory may pollute it, hence 
this is not recommended at all.


Best,
UWe
#
Dear Uwe,

Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source code 
is not polluted.

Furthermore, I forgot to mention that finally I upload the source code 
only to the BioC svn repository. The rest is done by the BioC servers, 
including building the pdf-files for the vignettes.

Best regards
Christian
On 5/3/11 10:13 PM, Uwe Ligges wrote:
#
On May 3, 2011, at 4:48 PM, cstrato <cstrato at aon.at> wrote:

            
But then you already used build to create the tar ball so the vignette has been built. So what is your point?

Cheers,
S
#
No, I simply do "tar czf xps_1.13.1.tar.gz xps".

Best regards
Christian
On 5/3/11 11:11 PM, Simon Urbanek wrote:
#
On May 3, 2011, at 5:15 PM, cstrato wrote:

            
Well, that's your problem then, not R's. Source packages are created using R CMD build, not by manual tarring (you can do the latter if you know what you're doing, but then you can't complain about the R doing something wrong).

Cheers,
S
#
Dear Simon,

I did not complain about the R doing something wrong. I only wanted to 
know why, after all these years, R CMD check does suddenly no longer 
build the pdf-files of the vignettes. I also think that this is a legal 
question.

Let me compare the times spent:

1, the "official" development cycle:
- R CMD build:   5 minutes
- R CMD INSTALL: 3 minutes
- R CMD check:   6 minutes

2, my own development cycle:
- manual tarring: 2 seconds
- R CMD check:    6 minutes

This means spending 14 minutes vs 6 minutes. If I assume that in one 
evening I have to make 10 corrections this would mean 140 minutes vs 60 
minutes, i.e. the official development cycle would take 1 hr and 20 min 
longer than my own development cycle. This is time I do not have.

Best regards
Christian
On 5/4/11 12:13 AM, Simon Urbanek wrote:
3 days later
#
Hi Christian,
On 11-05-04 01:02 PM, cstrato wrote:
My understanding is that R CMD INSTALL is not strictly necessary in
the official devel cycle. However, to be fair you should either include
that step in both cycles (devel and yours) or not. Then the numbers are
14 minutes vs 9 minutes (or 11 minutes vs 6 minutes).
No matter how you put it and how much benefits you get from this,
manual tarring is *wrong* and "after all these years" you should really
know this. Furthermore, here is what you claimed in a previous email:

   This is my development cycle:

   First, I run R CMD check until there are no more warnings/errors.
   Since years it was very convenient that R CMD check builds the
   pdf-files of the vignettes, too, since this allowed me to correct
   errors in the manual files and the vignette files at the same time!

   Afterwards I run R CMD INSTALL to install my package and do more
   tests until everything works.

   As you see I do not use R CMD build, since every run takes about
   5 minutes, it overwrites my zipped source code, and I would need
   to unzip it to get access to the vignette pdf-files.

You didn't mention the manual tarring.

Then later:

   Thank you, however since I use "R CMD INSTALL xps.tar.gz" my source
   code is not polluted.

So you are contradicting yourself.

   No, I simply do "tar czf xps_1.13.1.tar.gz xps".

Whaooo, finally! Note that, among other problems, this manual tarring
is very likely to pollute your source tree (this is one of the things
R CMD build will take care of).

You are free to do manual tarring for your own internal business if
you want, nobody cares, but you should keep this kind of dirty little
secrets for you. For your 10 corrections, you can do manual tarring
10 times, that's your problem, but that doesn't prevent you from doing
the right thing, i.e. R CMD build + R CMD check, as a *final* pass (e.g.
just before you commit your changes to svn). Now that means 71 minutes
vs 60 minutes, but you did the *right* thing.

Cheers,
H.

  
    
#
Dear Herve,

In my initial mail:
https://stat.ethz.ch/pipermail/r-devel/2011-April/060688.html
I wrote: "While R CMD check and R CMD INSTALL have always created the 
vignettes on R-2.12.1 or any earlier versions of R, I am no longer able 
to build the vignettes on R-2.13.0."

Although I made the mistake to include R CMD INSTALL, I wanted simply to 
know why R CMD check suddenly (after all these years) does no longer 
build the pdf-versions of the vignettes.

After many replies and discussions Prof. Ripley gave finally the answer:
https://stat.ethz.ch/pipermail/r-devel/2011-May/060782.html

I understand the reason for this and made the suggestion to include an 
option such as "--no-clean-vignettes" to R CMD check, since this would 
be a convenient option for me:
https://stat.ethz.ch/pipermail/r-devel/2011-May/060797.html

Best regards
Christian
On 5/8/11 9:29 PM, Herv? Pag?s wrote:
#
Christian,
On 11-05-08 01:19 PM, cstrato wrote:
and then someone tried to explain you that you didn't need that,
you just need to use the standard development cycle. And in your
last 5 emails you're still trying to convince the people around
that you have a better/faster development cycle that doesn't use
'R CMD build' at all. No matter this better development cycle is
broken, it should be supported anyway by adding a
"--no-clean-vignettes" option to 'R CMD check' just because
that would be a "convenient option for you"? I know, you are
just suggesting this option, but still...

H.

  
    
#
Dear Herve,

Since 'R CMD check' has already options '--no-vignettes' and 
'--no-rebuild-vignettes', so why not option '--no-clean-vignettes'?
But, as you admitted, it is only a suggestion.

Maybe it is time to close this thread.
(If you want we can discuss this issue further privately.)

Best regards
Christian
On 5/9/11 7:20 AM, Herv? Pag?s wrote: