[R-pkg-devel] problems with HTML version of manual
Hi. I am preparing a new version of package mnormt. The package installs OK locally, but R CMD check --as-cran --run-donttest mnormt_2.1.0.tar.gz runs fine only up to * checking PDF version of manual … OK and then it says * checking HTML version of manual ... NOTE Found the following problems: mnorm.Rd:4:1: Warning: inserting "type" attribute mnorm.Rd:12:1: Warning:
Re: [R-pkg-devel] install.packages() seems not to select the latest suitable version
Many thanks for your detailed explanations/annotations. Adelchi > On 28 Jul 2020, at 13:21, Dirk Eddelbuettel wrote: > > > Hi Adelchi, > > On 28 July 2020 at 11:46, Adelchi Azzalini wrote: > | When I updated package mnormt to version 2.0.0 in June (now at 2.0.1), > | at the stage of --as-cran checking, there was a compilation error, > | which was overcome by setting the > | > | Depends:R (≥ 4.0.0) > | > | With this option, all worked fine. > | > | However, shortly afterwards, complaints started coming, > | either from users or from maintainers of packages making use of mnormt, > | because this high version dependence causes troubles to some people, > | such as those using Debian installations, currently at a much lower > | R version. > > You can point those users to a) the r-sig-debian list and b) the Debian > directory at CRAN as we have always had "backports" of the current R to older > Debian releases---thanks to the work by Johannes Ranke "backporting" whatever > my current Debian packages of R are. > > Moreover, you can also point them at `apt install r-cran-mnormt` -- I have > maintained your package within Debian since 2007 (!!) and continue to do so > giving Debian (and Ubuntu) users the choice between a distro binary and > installation from CRAN source. > > | At the time I select that dependence value, I relied on the fact that > | install.packages() selected the most recent suitable version of a package, > | given the existing R installation. I expected that people without > | R 4.0.0 would have the older version of mnormt, 1.5-7, installed. > | As my memory goes (and the memory of other people too), this was > | the working in the past, but apparently not any more. > > I don't think that is quite correct. The CRAN repo is always set up for the > currently released version, and may allow constraints such 'R (>= 4.0.0)' > imposing the current (major) release. > > There is no recent change in this behavior. > > | For instance, this is a passage from a specific user: > | > | "install.packages() used tp just install the most recent available > | for your current version of R. In the past it might have done just that, > | but that's clearly not the case currently." > > Yes and no. I don't think this correctly stated. `install.packages()` always > picks the most recent version, but this may also require running _the > current_ R release. I disagree about "not the case currently" -- no change > as stated above. > > | Can anyone clarify the reason of this (apparent? real?) change? > | ...and possibly indicate a way who people with lower R version (and perhaps > | limited R expertise) can install the older version of mnormt, 1.5-7, > | without much hassle? > > "Versioned" installs were never supported by `install.packages()`. > > But one could always download an older version to a local file, and point > install.packages() at that file (and setting 'repos=NULL'), or use `R CMD > INSTALL` directly. No change there either. > > Dirk > > -- > https://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-pkg-devel] install.packages() seems not to select the latest suitable version
When I updated package mnormt to version 2.0.0 in June (now at 2.0.1), at the stage of --as-cran checking, there was a compilation error, which was overcome by setting the Depends:R (≥ 4.0.0) With this option, all worked fine. However, shortly afterwards, complaints started coming, either from users or from maintainers of packages making use of mnormt, because this high version dependence causes troubles to some people, such as those using Debian installations, currently at a much lower R version. At the time I select that dependence value, I relied on the fact that install.packages() selected the most recent suitable version of a package, given the existing R installation. I expected that people without R 4.0.0 would have the older version of mnormt, 1.5-7, installed. As my memory goes (and the memory of other people too), this was the working in the past, but apparently not any more. For instance, this is a passage from a specific user: "install.packages() used tp just install the most recent available for your current version of R. In the past it might have done just that, but that's clearly not the case currently." Can anyone clarify the reason of this (apparent? real?) change? ...and possibly indicate a way who people with lower R version (and perhaps limited R expertise) can install the older version of mnormt, 1.5-7, without much hassle? ---- Adelchi Azzalini http://azzalini.stat.unipd.it/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R] a question of etiquette
Thanks to all people that contributed to this discussion, which turned out to be interesting, definitely not something which I expected at the beginning. To avoid verbosity, I restrict myself to two more points. (1) In case one adopts the indication that all the authors of a portion of code (irrespective of the extension, even in other languages) are "of course now also copyright holders and authors", how should this be translated in the nomenclature of Writing R Extensions (Section 1.1.1 The DESCRIPTION file)? In this view, "ctb" is the more appropriate role, I believe. The "aut" label is not the right option. Otherwise, dozens on CRAN packages where "ctb" is extensively used should be amended. (2) Having read pertaining portions of manuals and pondered messages, I have come to the conclusion that the terminology set up in the above-quoted paragraph of "Writing R Extensions" is not always ideal. This issue would take a long time and space, so I only indicate one point: the role ‘"cre"’ (creator) for the package maintainer. There are many cases where this description does not fit. For instance, I have seen packages where an author has designed the package, written the entire code and documentation alone, maintained the package for some years, and then passed on the mere maintenance to somebody else; definitely, I would not describe the second person as the "creator". > > > So, I think the safe way is to include the original authors in the author > list (and check their license carefully). In general, "check the license" is a very sensible indication. In the specific case, the Matlab code comes with no licence indication - nothing. I have now submitted mnormt_2.0.0.tar.gz to CRAN, with a comment/query about this issue. Let us see what "The CRAN" says. In case you want see the conclusion, the outcome should appear at https://cran.r-project.org/package=mnormt in a few days. Best regards, Adelchi Azzalini __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R] a question of etiquette
Thanks for this information, Mark.
Given the phrase "small but important function my package uses", it seems
that you included in your package some code, reproducing it verbatim.
Do I understand correctly?
In my case, the code which I am actually using is the R porting of code
originally written in another language, namely Matlab.
Best wishes,
Adelchi
> On 1 Jun 2020, at 23:37, R. Mark Sharp wrote:
>
> Adelchi,
>
> I have a similar situation where I had made all of the typical academic
> references within the code and documentation for a small but important
> function my package uses. I was asked by the CRAN reviewers to add the author
> of that function to the DESCRIPTION Authors@R section. I added the following:
> person("Terry", "Therneau", role = c("aut”))
>
> Mark
> R. Mark Sharp, Ph.D.
> Data Scientist and Biomedical Statistical Consultant
> 7526 Meadow Green St.
> San Antonio, TX 78251
> mobile: 210-218-2868
> rmsh...@me.com
>
>
>
>
>
>
>
>
>
>
>
>> Begin forwarded message:
>>
>> From: Adelchi Azzalini
>> Subject: [R] a question of etiquette
>> Date: June 1, 2020 at 11:34:00 AM CDT
>> To: r-h...@r-project.org
>>
>> The new version of a package which I maintain will include a new function
>> which I have ported to R from Matlab.
>> The documentation of this R function indicates the authors of the original
>> Matlab code, reference to their paper, URL of the source code.
>>
>> Question: is this adequate, or should I include them as co-authors of the
>> package, or as contributors, or what else?
>> Is there a general policy about this matter?
>>
>> Adelchi Azzalini
>> http://azzalini.stat.unipd.it/
>>
>> __
>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R] a question of etiquette
The point in question does not refer to copying code, but to code translation.
Does this make any difference?
This was the question which I raised.
The phrase "As the code is part of the package now," does not seem to apply in
this case,
since the code is actually not there.
Also, if the authors of the original code (in Matlab) must be included in the
Authors@R
block of the DESCRIPTION file, should they be labelled as "aut", "cbt", or what?
Apart from the specific instance which my earlier question was referring to,
the view "As the code is part of the package now, therese are of course now
also copyright
holders and authors of your package" opens another question, closely related
but different,
as it refers to code which is included, not translated.
The above-quoted sentence appears to say that anyone who has written any
portion of code is an author of the package. In this view, who must be labelled
"cbt" then?
Best regards
Adelchi
> On 2 Jun 2020, at 01:25, Uwe Ligges wrote:
>
> If you copy code, you have to make sure that you can use it under the
> currrent license of your package, and you have to make sure to declare
> copright holders and authors. As the code is part of the package now, therese
> are of course now also copyright holders and authors of your package.
>
> Best,
> Uwe Ligges
>
> On 01.06.2020 23:37, R. Mark Sharp wrote:
>> Adelchi,
>> I have a similar situation where I had made all of the typical academic
>> references within the code and documentation for a small but important
>> function my package uses. I was asked by the CRAN reviewers to add the
>> author of that function to the DESCRIPTION Authors@R section. I added the
>> following:
>> person("Terry", "Therneau", role = c("aut”))
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>> Begin forwarded message:
>>>
>>> From: Adelchi Azzalini
>>> Subject: [R] a question of etiquette
>>> Date: June 1, 2020 at 11:34:00 AM CDT
>>> To: r-h...@r-project.org
>>>
>>> The new version of a package which I maintain will include a new function
>>> which I have ported to R from Matlab.
>>> The documentation of this R function indicates the authors of the original
>>> Matlab code, reference to their paper, URL of the source code.
>>>
>>> Question: is this adequate, or should I include them as co-authors of the
>>> package, or as contributors, or what else?
>>> Is there a general policy about this matter?
>>>
>>> Adelchi Azzalini
>>> http://azzalini.stat.unipd.it/
>>>
>>> __
>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>> [[alternative HTML version deleted]]
>> __
>> 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
