[Rd] How to address the following: CRAN packages not using Suggests conditionally
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 "22.214.171.124 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,
>> 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
>>> 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>>
>>> 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
>>> Just disable code chunk evaluation if suggested packages are
>>> missing (see ). 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.
>>>  https://www.enchufa2.es/archives/suggests-and-vignettes.html
>>> Thanks in advance for your kind assistance,
>>> Ulrich Bodenhofer
>>> -------- Forwarded Message --------
>>> Subject: Re: CRAN packages not using Suggests
>>> 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
>>> 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
>>> 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
>>> 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
>>> to multiple code chunks and also affect the validity of the
>>> in between. I would see the following options:
>>> 1. Remove the entire section of the vignette. That would be a
>>> since I can no longer point the users to an otherwise
>>> 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
>>> and also has much longer run times. Needless to say, the issue
>>> conditional loading will then simply propagate to 'kernlab'.
>>> Which of the three solutions would you prefer? Do you see any
>>> alternative? Or would you tolerate the warnings on some
>>> arising from the non-availability of packages suggested by the
>>> 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
>>> On 01/14/2018 09:20 AM, Prof Brian Ripley wrote:
>>> as required by §126.96.36.199 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),
>>> 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