[Rd] How to address the following: CRAN packages not using Suggests conditionally
Ulrich Bodenhofer
bodenhofer at bioinf.jku.at
Tue Jan 23 10:56:12 CET 2018
Thanks for your thoughts, Martin!
> It's very easy for 'pictures of code' (unevaluated code chunks in
> vignettes) to drift from the actual implementation. So I'd really
> encourage your conditional evaluation to be as narrow as possible --
> during CRAN or even CRAN fedora checks. Certainly trying to use
> uninstalled Suggest'ed packages in vignettes should provide an error
> message that is informative to users. Presumably the developer or user
> intends actually to execute the code, and needs to struggle through
> whatever issues come up.
I understand your point and I agree.
> I'm not sure whether my comments are consistent with Writing R
> Extensions or not.
I doubt that. My understanding of the section "1.1.3.1 Suggested
packages" is that conditional usage of suggested non-CRAN packages is
more or less required.
> There is a fundamental tension between the CRAN and Bioconductor
> release models. The Bioconductor 'devel' package repositories and
> nightly builds are meant to be a place where new features and breaking
> changes can be introduced and problems resolved before being exposed
> to general users as a stable 'release' branch, once every six months.
> This means that the Bioconductor devel branch periodically (as
> recently and I suspect over the next several days) contains
> considerable carnage that propagates to CRAN devel builds, creating
> additional work for CRAN maintainers.
I am aware of these different philosophies. Though I have an opinion
about this matter, it is pointless which model I like better. As a
developer, I have to respect the rules, period. It seems that I can
avoid trouble by avoiding any dependency to Bioconductor in my CRAN
packages. In the case of the 'apcluster' package, I deliberately chose
trouble ;-) because I think that exemplar-based clustering of
biological sequences by means of sequence kernels is a very cool thing
that users should be made aware of.
If I could make a wish to a fairy, I'd ask her to initiate a
constructive discussion between the R Core Team and the Bioconductor
Core Team to sort these things out, such that the "tensions" (as you
have put it) are no longer left as a burden to the package developers.
Thanks and best regards,
Ulrich
>
>>
>> On 01/22/2018 10:16 AM, Iñaki Úcar wrote:
>>> Re-sending, since I forgot to include the list, sorry. I'm including
>>> r-package-devel too this time, as it seems more appropriate for this
>>> list.
>>>
>>>
>>> El 22 ene. 2018 10:11, "Iñaki Úcar" <i.ucar86 at gmail.com
>>> <mailto:i.ucar86 at gmail.com>> escribió:
>>>
>>>
>>>
>>> El 22 ene. 2018 8:12, "Ulrich Bodenhofer"
>>> <bodenhofer at bioinf.jku.at <mailto:bodenhofer at bioinf.jku.at>>
>>> escribió:
>>>
>>> Dear colleagues, dear members of the R Core Team,
>>>
>>> This was an issue raised by Prof. Brian Ripley and sent
>>> privately to all developers of CRAN packages that suggest
>>> Bioconductor packages (see original message below). As
>>> mentioned in my message enclosed below, it was easy for me to
>>> fix the error in examples (new version not submitted to CRAN
>>> yet), but it might turn into a major effort for the warnings
>>> raised by the package vignette. Since I have not gotten any
>>> advice yet, I take the liberty to post it here on this list -
>>> hoping that we reach a conclusion here how to deal with this
>>> matter.
>>>
>>>
>>> Just disable code chunk evaluation if suggested packages are
>>> missing (see [1]). As explained by Prof. Ripley, it will only
>>> affect Fedora checks on r-devel, i.e., your users will still see
>>> fully evaluated vignettes on CRAN.
>>>
>>> [1] https://www.enchufa2.es/archives/suggests-and-vignettes.html
>>> <https://www.enchufa2.es/archives/suggests-and-vignettes.html>
>>>
>>> Iñaki
>>>
>>>
>>> Thanks in advance for your kind assistance,
>>> Ulrich Bodenhofer
>>>
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: Re: CRAN packages not using Suggests
>>> conditionally
>>> Date: Mon, 15 Jan 2018 08:44:40 +0100
>>> From: Ulrich Bodenhofer <bodenhofer at bioinf.jku.at
>>> <mailto:bodenhofer at bioinf.jku.at>>
>>> To: Prof Brian Ripley <ripley at stats.ox.ac.uk
>>> <mailto:ripley at stats.ox.ac.uk>>
>>> CC: [...stripped for the sake of privacy ...]
>>>
>>>
>>>
>>> Dear Prof. Ripley,
>>>
>>> Thank you very much for bringing this important issue to my
>>> attention. I
>>> am the maintainer of the 'apcluster' package. My package
>>> refers to
>>> 'Biostrings' in an example section of a help page (a quite
>>> insignificant
>>> one, by the way), which creates errors on some platforms. It
>>> also refers
>>> to 'kebabs' in the package vignette, which leads to warnings.
>>>
>>> I could fix the first, more severe, problem quite easily, (1)
>>> since it
>>> is relatively easy to wrap an entire examples section in a
>>> conditional,
>>> and (2), as I have mentioned, it is not a particularly
>>> important help page.
>>>
>>> Regarding the vignette, I want to ask for your advice now,
>>> since the
>>> situation appears more complicated to me. While it is, of
>>> course, only
>>> one code chunk that loads the 'kebabs' package, five more code
>>> chunks
>>> depend on the package (more specifically, the data objects
>>> created by a
>>> method implemented in the package) - with quite some text in
>>> between. So
>>> the handling of the conditional loading of the package would
>>> propagate
>>> to multiple code chunks and also affect the validity of the
>>> explanations
>>> in between. I would see the following options:
>>>
>>> 1. Remove the entire section of the vignette. That would be a
>>> pity,
>>> since I can no longer point the users to an otherwise
>>> interesting
>>> application of my package.
>>> 2. Replace the code chunks by static LaTeX code such that it
>>> appears in
>>> the PDF as if there were code chunks that had been run. This
>>> sort of
>>> undermines the philosophy of vignettes and also creates extra
>>> effort for
>>> me to maintain the vignette.
>>> 3. Use the functionality of 'kernlab' instead of 'kebabs' if
>>> the latter
>>> is not available. This would be technically possible, but (1)
>>> the code
>>> in the vignette will look much more complicated to the user
>>> and (2)
>>> 'kernlab' does not implement the necessary functionality fully
>>> correctly
>>> and also has much longer run times. Needless to say, the issue
>>> with
>>> conditional loading will then simply propagate to 'kernlab'.
>>>
>>> Which of the three solutions would you prefer? Do you see any
>>> fourth
>>> alternative? Or would you tolerate the warnings on some
>>> platforms
>>> arising from the non-availability of packages suggested by the
>>> package
>>> vignette?
>>>
>>> Thanks for your time and best regards,
>>> Ulrich Bodenhofer
>>>
>>> P.S.: @all: I hope it is acceptable that I replied to all. I
>>> thought the
>>> discussion would be interesting for some of you having similar
>>> issues.
>>>
>>>
>>>
>>> On 01/14/2018 09:20 AM, Prof Brian Ripley wrote:
>>>
>>> as required by §1.1.3.1 of the manual.
>>>
>>> The Bioconductor branch used by R-devel has been very
>>> unstable recently, and it has been decided not to use it
>>> for the Fedora checks on R-devel. As you can see from the
>>> CRAN results pages (at least at the time of writing),
>>> packages
>>>
>>> ACMEeqtl BoSSA CNVassoc CorShrink GRANBase GenCAT GiANT
>>> NMF PlackettLuce ProFit ProFound RNAseqNet SIBERG
>>> antaresRead apcluster cherry clValid coloc colorhcplot
>>> entropart filematrix fuzzyforest fuzzyjoin glycanr hexbin
>>> loon nscancor ordinalgmifs penalized phangorn propr shiftR
>>> switchr tcgsaseq tileHMM tmod
>>>
>>> then give ERRORs or (new) WARNINGs on their checks.
>>> Please correct ASAP, and by Feb 20 to safely retain the
>>> package on CRAN.
More information about the R-devel
mailing list