Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran

[Bernd . Gruber]

Thanks, just to make sure:

In the policy I find the entry:

Additional_repositories:

The ‘Additional_repositories’ field is a comma-separated list of repository 
URLs where the packages named in the other fields may be found. It is currently 
used by R CMD check to check that the packages can be found, at least as source 
packages (which can be installed on any platform).

And here I would have to provide an url that links to the tar.gz file of the 
package, or can I also provide

The ‘Additional_repositories’ field is a comma-separated list of repository 
URLs where the packages named in the other fields may be found. It is currently 
used by R CMD check to check that the packages can be found, at least as source 
packages (which can be installed on any platform).

github::green-striped-gecko/dartR.popgenomics

similar to the Remotes: field (which I think is not possible to use).

Thanks,


==
Dr Bernd Gruber  )/_
 _.--..---"-,--c_
Professor Ecological Modelling  \|..'   ._O__)_
Tel: (02) 6206 3804 ,=._.+   _ \..--( /
Fax: (02) 6201 2328   \\.-''_.-' \ ( \_
Institute for Applied Ecology  `'''   `\__   /\
Faculty of Science and Technology  ')
University of Canberra   ACT 2601 AUSTRALIA
Email: bernd.gru...@canberra.edu.au
WWW: 
bernd-gruber

Australian Government Higher Education Provider Number CRICOS #00212K
NOTICE & DISCLAIMER: This email and any files transmitted with it may contain
confidential or copyright material and are for the attention of the addressee
only. If you have received this email in error please notify us by email
reply and delete it from your system. The University of Canberra accepts
no liability for any damage caused by any virus transmitted by this email.
==

From: Uwe Ligges 
Sent: Sunday, 25 June 2023 20:51
To: Bernd.Gruber 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and 
how to submit them to cran



On 25.06.2023 09:00, Bernd.Gruber wrote:
> Hi,
>
> Thanks for the advice.
>
> Still not 100% sure if that is okay to submit to CRAN.
>
> As mentioned I have new packages that have others in the suggest (and yes the 
> examples/tests run fine by making the dependent),
>
> But if I have a package that is not yet on CRAN in the suggest I see that 
> running winbuilder.
>
> Suggests or Enhances not in mainstream repositories:
> dartR.sim

If it is not in a mainstream repo, you can declare where users can get
it from, see the explanation in the CRAN policies how to declare it.



> * checking package namespace information ... OK
> * checking package dependencies ... NOTE
> Package suggested but not available for checking: 'dartR.sim'

This is OK, once the former is explained.

Best,
Uwe Ligges


>
>
>
>
> Can I explain when I submit that dartR.sim will be there (as mentioned the 
> examples run fine), but obviously is not yet on CRAN.
>
> I assume the same would happen if I put the new packages in Enhances…
>
> Regards, Bernd
>
>
>
>
> From: Thierry Onkelinx 
> mailto:thierry.onkel...@inbo.be>>
> Sent: Friday, June 23, 2023 5:51 PM
> To: Simon Urbanek 
> mailto:simon.urba...@r-project.org>>
> Cc: Bernd.Gruber 
> mailto:bernd.gru...@canberra.edu.au>>; 
> r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and 
> how to submit them to cran
>
> Dear Bernd,
>
> You could contact the maintainer of the spatstat package. They did the same 
> thing (splitting a large package into several smaller ones) a few years ago.
>
> Having the base package suggesting an add-on and the add-on depending on or 
> suggesting the base package might create an unwanted loop.
>
> Best regards,
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND 
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be>
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be>
> ///
> To call in the statistician after the experiment is done may be no more than 
> asking him to perform a post-mortem examination: he may be able to say what 
> the experiment died of. ~ Sir Ronald Aylmer Fisher
> The p

Re: [R-pkg-devel] Nickname allowed in description when submitting to CRAN?

[Bernd . Gruber]

Thanks for the advice. Revision sounds perfectly plausible to me. I will test 
via winbuilder and may use it.

Regards, Bernd


==
Dr Bernd Gruber  )/_  
 _.--..---"-,--c_ 
Professor Ecological Modelling  \|..'   ._O__)_ 
 
Tel: (02) 6206 3804 ,=._.+   _ \..--( /   
Fax: (02) 6201 2328   \\.-''_.-' \ ( \_   
Institute for Applied Ecology  `'''   `\__   /\   
Faculty of Science and Technology  ') 
University of Canberra   ACT 2601 AUSTRALIA
Email: bernd.gru...@canberra.edu.au
WWW: bernd-gruber

Australian Government Higher Education Provider Number CRICOS #00212K 
NOTICE & DISCLAIMER: This email and any files transmitted with it may contain 
confidential or copyright material and are for the attention of the addressee 
only. If you have received this email in error please notify us by email 
reply and delete it from your system. The University of Canberra accepts 
no liability for any damage caused by any virus transmitted by this email.
==

-Original Message-
From: Ivan Krylov  
Sent: Sunday, 25 June 2023 17:35
To: Bernd.Gruber 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Nickname allowed in description when submitting to 
CRAN?

В Sun, 25 Jun 2023 06:30:39 +
Bernd.Gruber  пишет:

> I read in some stackexchange answers that it is possible to add the 
> keyword
> 
> Nickname:
> 
> to the description file. It works fine when I check the package but 
> winbuilder comes back with a note:
> 
> Unknown, possibly misspelled, fields in DESCRIPTION:
>   'Nickname'
> 
> So the question is, is there a way to have a nickname for a version of 
> an R package and if so, how would that be done.

I'm afraid it's not exactly documented (and therefore may be subject to 
change), but this NOTE is currently produced for every DESCRIPTION field unless 
it's mentioned in tools:::.get_standard_DESCRIPTION_fields() or starts with a 
number of prefixes (such as X-CRAN, X-schema.org, Repository/R-Forge, VCS/, and 
Config/).

I see "Revision" in the list of standard DESCRIPTION fields.
Conveniently, it doesn't seem to be used by base R packages. Would it be 
acceptable to use "Revision" instead of "Nickname"?

An alternative option would be to file a wishlist ticket asking for "Nickname" 
to be added to the list, but then your package will have to wait until that 
change propagates to the next release of R.

--
Best regards,
Ivan

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

Re: [R-pkg-devel] Convention or standards for using header library (e.g. Eigen)

[Uwe Ligges]

On 24.06.2023 19:44, Dirk Eddelbuettel wrote:


On 24 June 2023 at 21:35, Stephen Wade wrote:
| Doesnt seem like the system package is worth it. Should the convention
| simply be to bundle the headers in the package then? What about package
| size - is there some limit to the size of included libraries/headers to
| consider for CRAN?

Here is one (drastic) example:

   $ du -csh /usr/local/lib/R/site-library/BH
   156M/usr/local/lib/R/site-library/BH
   156Mtotal
   $



Of course one should always try to keep software as small as possible 
and not waste space.
For binary packages, we are aware that some packages are large for the 
reason Dirk explains. CRAN typically does not complain here, although 
there are cases where we have to consider if it makes sense to 
distribute that huge software is system libraries may be available.


The size restriction that applies for CRAN packages is the 5MB threshold 
for the source package size.


Best,
Uwe Ligges



Note that the package was smaller when it started (in 2013). (Note that the
last time I checked its size, the largest (not just headers) package I know
of on CRAN still was about twice as large still.)

Anyway: as you are starting to see, this is a somewhat complex problem.
Header packages are one approach. _Writing R Extensions_ mentions pure header
packages and name-checks my packages BH, RcppArmadillo and RcppEigen in
Section 1.1.3. I once wrote a short paper on this [1] (also a vignette [2])
where I more or less recommend header packages because compiled ones are so
much harder.  Recognise for example that a) no cross-OS way to check for
packages exists (though pkg-config comes close), b) no general package
managers exist, c) configure and cmake come close (but cmake is also an added
system requirement; and configure is a no-show on Windows) and d) even within
a given OS and release you may have very different versions. Lastly also: e)
some packages (RcppEigen is an example) have patches the system library would
not have applied (!!).

So to me a simplified view is that just as R "abstracts away" POSIX so that
we can always say e.g. 'dir.exists(path)' no matter where R runs, having a
package with headers ensure we get a consistent _and reliable_ compilation
experience from client packages. This matters.

Now, there are clearly downsides. With my Debian maintainer hat on, I have to
defend including Armadillo withon RcppArmadillo because the distro has it too
(but then version skew ie d) above and ease of use and consistency etc
dominate so we continue to ship RcppArmadillo).  At the same time, at CRAN we
have needless duplications. For example, my RcppCCTZ package was the first to
offer the nice (Google made but not a Google 'product') CCTZ library for R
use (starting in 2015). But when I last checked a year or so ago, four other
packages now included redundant extra copies. Also happens with Eigen. Not
great.

On the other side, packages with full (included or not) libraries work too,
but they are more effort to portably provide them, to explain to users where
to get them and keep them current and so.  It is hard (or even impossible)
for R to fill in as a _general system_ package manager across all OSs and
deployments.  There is a new kid on this block [3] we are starting to use at
work, and which may help in time across the platforms that R uses. To be
seen...

So to sum up: I think header packages are great, and I maintain a few, both
large and small in size.  I would encourage you to try them. For RcppEigen,
you can just use LinkingTo: to gets its headers.  Some 400+ packages rely on
it. (And its over 1000 for Armadillo now, and over 300 for BH.)

Hth,  Dirk

[1] https://arxiv.org/abs/1911.06416
[2] https://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-libraries.pdf
[3] https://vcpkg.io/en/



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

Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran

[Uwe Ligges]

On 25.06.2023 09:00, Bernd.Gruber wrote:

Hi,

Thanks for the advice.

Still not 100% sure if that is okay to submit to CRAN.

As mentioned I have new packages that have others in the suggest (and yes the 
examples/tests run fine by making the dependent),

But if I have a package that is not yet on CRAN in the suggest I see that 
running winbuilder.

Suggests or Enhances not in mainstream repositories:
   dartR.sim


If it is not in a mainstream repo, you can declare where users can get 
it from, see the explanation in the CRAN policies how to declare it.





* checking package namespace information ... OK
* checking package dependencies ... NOTE
Package suggested but not available for checking: 'dartR.sim'


This is OK, once the former is explained.

Best,
Uwe Ligges







Can I explain when I submit that  dartR.sim will be there (as mentioned the 
examples run fine), but obviously is not yet on CRAN.

I assume the same would happen if I put the new packages in Enhances…

Regards, Bernd




From: Thierry Onkelinx 
Sent: Friday, June 23, 2023 5:51 PM
To: Simon Urbanek 
Cc: Bernd.Gruber ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and 
how to submit them to cran

Dear Bernd,

You could contact the maintainer of the spatstat package. They did the same 
thing (splitting a large package into several smaller ones) a few years ago.

Having the base package suggesting an add-on and the add-on depending on or 
suggesting the base package might create an unwanted loop.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND 
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be
///
To call in the statistician after the experiment is done may be no more than 
asking him to perform a post-mortem examination: he may be able to say what the 
experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not ensure 
that a reasonable answer can be extracted from a given body of data. ~ John 
Tukey
///

[https://inbo-website-prd-532750756126.s3-eu-west-1.amazonaws.com/inbologoleeuw_nl.png]


Op vr 23 jun 2023 om 06:52 schreef Simon Urbanek 
mailto:simon.urba...@r-project.org>>:
Bernd,

the sequence in which you submit doesn't matter - the packages have to work 
regardless of the sequence. Suggests means that the dependency is optional, not that 
it can break tests. You have to skip the tests that cannot be run due to missing 
dependencies (see 1.1.3.1 in R-exts)

Cheers,
Simon




On Jun 23, 2023, at 2:35 PM, Bernd.Gruber 
mailto:bernd.gru...@canberra.edu.au>> wrote:

Hi,

I have a question regarding the separation of a package into smaller pieces (to 
avoid long testing/installation times and more important to avoid to many 
dependencies)

I am the maintainer of an R package (dartR) which has grown and is now at the 
limit in terms of testing/run time and also dependencies. To further develop 
the package we started to break the package into smaller packages namely


Two core packages (dartR.base and dartR.data) and here dartR.base has 
dartR.data in the depends. (dartR.base is 60% of the previous package) and 
dartR.data is our data.package for test data (dartR.data is already on CRAN)




Next to the two core packages we also have 3 more addon packages that deal with 
specialised analysis

dartR.sim
dartR.spatial
dartR.popgenomics.

Those packages depend on dartR.base and dartR.data.

All addon packages and core packages should have the other addon packages as 
suggests, hence here comes the question.


How do I submit the packages?  All of them at once? Or step by step.

If I submit step by step (e.g. dartR.base) it obviously cannot have the other 
dartR addon packages as suggests (cannot be tested and will break the CRAN 
tests).

So would be the correct way to:
Submit dartR.base (without dartR.sim, dartR.spatial and dartR.popgenomics in 
the suggest.)
Then submit dartR.sim, then dartR.spatial and finally dartR.popgenomics (all 
without suggests of the other packages)

And finally update all packages (only their description file and add the 
suggests once they are on CRAN).

Hope that makes sense and thanks in advance,

Bernd



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

[

Re: [R-pkg-devel] Nickname allowed in description when submitting to CRAN?

[Ivan Krylov]

В Sun, 25 Jun 2023 06:30:39 +
Bernd.Gruber  пишет:

> I read in some stackexchange answers that it is possible to add the
> keyword
> 
> Nickname:
> 
> to the description file. It works fine when I check the package but
> winbuilder comes back with a note:
> 
> Unknown, possibly misspelled, fields in DESCRIPTION:
>   'Nickname'
> 
> So the question is, is there a way to have a nickname for a version
> of an R package and if so, how would that be done.

I'm afraid it's not exactly documented (and therefore may be subject to
change), but this NOTE is currently produced for every DESCRIPTION field
unless it's mentioned in tools:::.get_standard_DESCRIPTION_fields() or
starts with a number of prefixes (such as X-CRAN, X-schema.org,
Repository/R-Forge, VCS/, and Config/).

I see "Revision" in the list of standard DESCRIPTION fields.
Conveniently, it doesn't seem to be used by base R packages. Would it
be acceptable to use "Revision" instead of "Nickname"?

An alternative option would be to file a wishlist ticket asking for
"Nickname" to be added to the list, but then your package will have to
wait until that change propagates to the next release of R.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Questions regarding a new (seperated package) and how to submit them to cran

[Bernd . Gruber]

Hi,

Thanks for the advice.

Still not 100% sure if that is okay to submit to CRAN.

As mentioned I have new packages that have others in the suggest (and yes the 
examples/tests run fine by making the dependent),

But if I have a package that is not yet on CRAN in the suggest I see that 
running winbuilder.

Suggests or Enhances not in mainstream repositories:
  dartR.sim

* checking package namespace information ... OK
* checking package dependencies ... NOTE
Package suggested but not available for checking: 'dartR.sim'





Can I explain when I submit that  dartR.sim will be there (as mentioned the 
examples run fine), but obviously is not yet on CRAN.

I assume the same would happen if I put the new packages in Enhances…

Regards, Bernd




From: Thierry Onkelinx 
Sent: Friday, June 23, 2023 5:51 PM
To: Simon Urbanek 
Cc: Bernd.Gruber ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Questions regarding a new (seperated package) and 
how to submit them to cran

Dear Bernd,

You could contact the maintainer of the spatstat package. They did the same 
thing (splitting a large package into several smaller ones) a few years ago.

Having the base package suggesting an add-on and the add-on depending on or 
suggesting the base package might create an unwanted loop.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND 
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be
///
To call in the statistician after the experiment is done may be no more than 
asking him to perform a post-mortem examination: he may be able to say what the 
experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not ensure 
that a reasonable answer can be extracted from a given body of data. ~ John 
Tukey
///

[https://inbo-website-prd-532750756126.s3-eu-west-1.amazonaws.com/inbologoleeuw_nl.png]


Op vr 23 jun 2023 om 06:52 schreef Simon Urbanek 
mailto:simon.urba...@r-project.org>>:
Bernd,

the sequence in which you submit doesn't matter - the packages have to work 
regardless of the sequence. Suggests means that the dependency is optional, not 
that it can break tests. You have to skip the tests that cannot be run due to 
missing dependencies (see 1.1.3.1 in R-exts)

Cheers,
Simon



> On Jun 23, 2023, at 2:35 PM, Bernd.Gruber 
> mailto:bernd.gru...@canberra.edu.au>> wrote:
>
> Hi,
>
> I have a question regarding the separation of a package into smaller pieces 
> (to avoid long testing/installation times and more important to avoid to many 
> dependencies)
>
> I am the maintainer of an R package (dartR) which has grown and is now at the 
> limit in terms of testing/run time and also dependencies. To further develop 
> the package we started to break the package into smaller packages namely
>
>
> Two core packages (dartR.base and dartR.data) and here dartR.base has 
> dartR.data in the depends. (dartR.base is 60% of the previous package) and 
> dartR.data is our data.package for test data (dartR.data is already on CRAN)
>
>
>
>
> Next to the two core packages we also have 3 more addon packages that deal 
> with specialised analysis
>
> dartR.sim
> dartR.spatial
> dartR.popgenomics.
>
> Those packages depend on dartR.base and dartR.data.
>
> All addon packages and core packages should have the other addon packages as 
> suggests, hence here comes the question.
>
>
> How do I submit the packages?  All of them at once? Or step by step.
>
> If I submit step by step (e.g. dartR.base) it obviously cannot have the other 
> dartR addon packages as suggests (cannot be tested and will break the CRAN 
> tests).
>
> So would be the correct way to:
> Submit dartR.base (without dartR.sim, dartR.spatial and dartR.popgenomics in 
> the suggest.)
> Then submit dartR.sim, then dartR.spatial and finally dartR.popgenomics (all 
> without suggests of the other packages)
>
> And finally update all packages (only their description file and add the 
> suggests once they are on CRAN).
>
> Hope that makes sense and thanks in advance,
>
> Bernd
>

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

[[alternative HTML version deleted]]

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