How to address the following: CRAN packages not using Suggests conditionally

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How to address the following: CRAN packages not using Suggests conditionally

Ulrich Bodenhofer
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.

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 <[hidden email]>
To: Prof Brian Ripley <[hidden email]>
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.
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to address the following: CRAN packages not using Suggests conditionally

Iñaki Úcar
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" <[hidden email]> escribió:

>
>
> El 22 ene. 2018 8:12, "Ulrich Bodenhofer" <[hidden email]>
> 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
>
> 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 <[hidden email]>
> To:     Prof Brian Ripley <[hidden email]>
> 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.
>>
>>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to address the following: CRAN packages not using Suggests conditionally

Ulrich Bodenhofer
Thanks a lot, Iñaki, this is a perfect solution! I already implemented
it and it works great. I'll wait for 2 more days before I submit the
revised package to CRAN - in order to give others to comment on it.

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" <[hidden email]
> <mailto:[hidden email]>> escribió:
>
>
>
>     El 22 ene. 2018 8:12, "Ulrich Bodenhofer"
>     <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]
>         <mailto:[hidden email]>>
>         To:     Prof Brian Ripley <[hidden email]
>         <mailto:[hidden email]>>
>         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.
>
>
>         ______________________________________________
>         [hidden email] <mailto:[hidden email]> mailing list
>         https://stat.ethz.ch/mailman/listinfo/r-devel
>         <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to address the following: CRAN packages not using Suggests conditionally

Martin Morgan-3
On 01/22/2018 08:40 AM, Ulrich Bodenhofer wrote:
> Thanks a lot, Iñaki, this is a perfect solution! I already implemented
> it and it works great. I'll wait for 2 more days before I submit the
> revised package to CRAN - in order to give others to comment on it.

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'm not sure whether my comments are consistent
with Writing R Extensions or not.

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.

Martin Morgan
Bioconductor

>
> 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" <[hidden email]
>> <mailto:[hidden email]>> escribió:
>>
>>
>>
>>     El 22 ene. 2018 8:12, "Ulrich Bodenhofer"
>>     <[hidden email] <mailto:[hidden email]>>
>> 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 <[hidden email]
>>         <mailto:[hidden email]>>
>>         To:     Prof Brian Ripley <[hidden email]
>>         <mailto:[hidden email]>>
>>         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.
>>
>>
>>         ______________________________________________
>>         [hidden email] <mailto:[hidden email]> mailing list
>>         https://stat.ethz.ch/mailman/listinfo/r-devel
>>         <https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


This email message may contain legally privileged and/or...{{dropped:2}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to address the following: CRAN packages not using Suggests conditionally

Ulrich Bodenhofer
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" <[hidden email]
>>> <mailto:[hidden email]>> escribió:
>>>
>>>
>>>
>>>     El 22 ene. 2018 8:12, "Ulrich Bodenhofer"
>>>     <[hidden email] <mailto:[hidden email]>>
>>> 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 <[hidden email]
>>>         <mailto:[hidden email]>>
>>>         To:     Prof Brian Ripley <[hidden email]
>>>         <mailto:[hidden email]>>
>>>         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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel