Re: [R-pkg-devel] [Rd] 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"  escribió:

>
>
> El 22 ene. 2018 8:12, "Ulrich Bodenhofer" 
> 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 
> To: Prof Brian Ripley 
> 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.
>>
>>
> __
> r-de...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

[[alternative HTML version deleted]]

_

Re: [R-pkg-devel] Conditionally register method with generic in other package

[Joshua Ulrich]

For posterity, the solution I employed did not register the method as
a formal S3 method.  Functionality in package B was unchanged as long
as package B was loaded and attached... which was good enough for my
purposes.

On Wed, Dec 6, 2017 at 6:45 AM, Joshua Ulrich  wrote:
> I have a feeling I know the answer to this question, but I'm asking
> with the hope that I learn something new.
>
> Package A defines a S3 generic function, "foo()".  Package B defines a
> S3 class "bar", and a foo.bar() method.  This method is not strictly
> necessary for the package to function, and package A has many
> dependencies.
>
> To avoid excessive dependencies, I would like to only register
> foo.bar() if package A is installed at the time package B is
> installed.  If package A is installed after package B, then warn the
> user when package B is loaded and/or attached, so they can re-install
> A and have foo.bar() registered correctly.
>
> I could figure out a way to do this manually, but doubt it would be
> CRAN-approved.  What is the recommended way to handle this situation?
> I've received one suggestion to split B into 2 packages: one without
> the method, and one with.  Are there other alternatives?
>
> Thanks,
> Josh
>
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
> R/Finance 2018 | www.rinfinance.com



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com
R/Finance 2018 | www.rinfinance.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Rd] 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" > escribió:




El 22 ene. 2018 8:12, "Ulrich Bodenhofer"
mailto:bodenho...@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


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 mailto:bodenho...@bioinf.jku.at>>
To:     Prof Brian Ripley mailto:rip...@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

Re: [R-pkg-devel] Licensing of an R package

[Martyn Plummer]

On Fri, 2018-01-19 at 20:28 +, Chris Brien wrote:
> Hi Dirk & Duncan,
> 
> I too like GPL and I had thought that the situation was as Duncan
> outlines. Consequently, I had licensed `foo' as GPL >= 2.
> 
> However, because I have been unable to find a discussion of my case,
> in spite of the extensive material about GNU licensing on the web, I
> have had difficulty deciding whether or not I was mistaken in
> applying a GPL license. 
> 
> It does seem that the open source philosophy is that all software
> should be open source and GPL licensing is to promote this, which it
> does by restricting how you can apply GPL licensing. It would be
> consistent with this philosophy that GPL does not allow one to `link'
> with a commercial package. However, somewhat reluctantly it seems, an
> exception is made under GPL licensing  for linking to commercial
> `system libraries' because it is necessary to allow this for things
> like R etc. 
> 
> If Bloomberg API is a system library then it also qualifies as an
> exception. (I have seen the license file and note that you are able
> to distribute the API.)
> 
> In my case `bar' is asreml and I don't believe that it qualifies as a
> system library. However, I can use it to build my library
> (asremlPlus) and the maintainers and license owners know that I do
> this. As a result I am still unsure that GPL can be applied in my
> case.
> 
> Ugh! It is a minefield.

It is not as bad as you think. 

The FSF admits that sometimes you need to link to a non-free library.
They just ask you not to do it if a free replacement is available:
https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs

As Duncan points out, your choice of license does not affect what you
can do with it. As copyright holder, you can do what you like (modulo
restrictions placed on you by the asreml license). The question is what
rights you want to confer to other people.

GPL is based on copyright law, so the rights and obligations it confers
come into effect only when the software is distributed (or "conveyed"
in the updated language of GPL 3) to a third party. These rights and
obligations also apply to any derived works, which means both modified
source code and binary packages created from the source code.

With a GPL license, anyone has the right to do the following with your
asremlPlus package:

1) Distribute the source package.

2) Distribute modified versions of the source package under the same
GPL conditions.

3) Install and use the asremlPlus package linked to the asreml library.
 

What they cannot do with a standard GPL license is:

4) Distribute a binary package of asremlPlus linked to asreml

Distributing a binary package of asremlPlus under the GPL comes with
the obligation to provide the source code to asreml which, of course,
cannot be done.

It should also be noted that the license terms of asreml itself may
prevent distribution of a binary package of asremlPlus.

However, if there are no such restrictions then nothing prevents you as
sole copyright holder from creating your own (dynamically linked)
binaries and distributing them to your users.

If you do want to give your users rights to distribute binary packages
then you may add an explicit exception to the GPL to your software
license. The FSF provides a template to add this exception to your
license:

https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

Martyn


> Thanks muchly for your input.
> 
> Cheers,
> 
>   Chris
> 
> 
> -Original Message-
> From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On
> Behalf Of Dirk Eddelbuettel
> Sent: Saturday, 20 January 2018 2:30 AM
> To: Duncan Murdoch
> Cc: Chris Brien; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Licensing of an R package
> 
> 
> Chris,
> 
> I am with Duncan here.
> 
> You can license _your_ package any way you want and prefer. I like
> GPL.
> 
> You seem to imply that the GPL license prohibits linking against
> commercial code.  If that were the case we'd never have R, Emacs,
> gcc/g++, ... on Windows or macOS or any of the now-essentially-
> extinct commercial Unux flavours.  We alway link against their system
> libraries too.
> 
> Also look eg at our Rblpapi package.  The Bloomberg API is not open
> source, but they allow distribution of the (pre-built) library and
> headers.  Our package, building on top, is GPL-2+. No issues.  (This
> example is extra fun because CRAN can't distribute the API, but can
> use it for building our package. Using the package requires having a
> commercial and expensive Bloomberg terminal license and
> installation.)
> 
> Dirk
> 
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel