[R-pkg-devel] RES: RES: Time for CRAN response
Thanks, Duncan and Uwe, for the answers! I'll resubmit it as soon as possible. Best regards, Tiago Olivoto -- M.Sc. Tiago Olivoto Doutorando em Agronomia Departamento de Fitotecnia Universidade Federal de Santa Maria Av. Roraima, 1000, Camobi Santa Maria, RS, 97105-340 E-mail: tiagooliv...@gmail.com Cel: +55 54 999187863 Research Gate Currículo Lattes -Mensagem original- De: Uwe Ligges Enviada em: domingo, 15 de dezembro de 2019 22:27 Para: Duncan Murdoch ; tiagooliv...@gmail.com; r-package-devel@r-project.org Assunto: Re: [R-pkg-devel] RES: Time for CRAN response On 15.12.2019 23:39, Duncan Murdoch wrote: > On 15/12/2019 4:57 p.m., Tiago Olivoto wrote: >> Thank you for the response. >> As far I remember, I've responded that message by following the link >> and selecting "I have read the CRAN policies and would like to submit >> this package to CRAN" and " I have checked the submission using R CMD >> check --as-cran and a current version of r-devel, as mandated by the >> CRAN Repository Policy. (You could do so using the win-builder >> service at https://win-builder.r-project.org)", and then clicking on >> "upload package to CRAN" >> These same steps were followed in the first submission, but at that >> time I received the following message that was not received in the >> last submission. >> >>> Dear maintainer, >>> >>> package metan_1.0.0.tar.gz has been auto-processed and is pending a >>> manual inspection of this new CRAN submission. A CRAN team member >>> will typically respond to you within the next 10 working days. >> >> Should I try to re-submit it again? > > Probably. I'd wait 24 hours, to see if someone from CRAN replies with > more information. > Thanks, Duncan, here we got: 1. I did not spot a request for help from Nov 25 in the many messsages we receive. That one has now been answered. 2. I do not see a submission fom Nov 25. Can you simply resubmit and make sure you click on the confirmation link? Best, Uwe Ligges > Duncan Murdoch > >> Best, >> Tiago Olivoto >> >> >> -Mensagem original- >> De: Duncan Murdoch Enviada em: domingo, 15 >> de dezembro de 2019 17:35 >> Para: tiagooliv...@gmail.com; r-package-devel@r-project.org >> Assunto: Re: [R-pkg-devel] Time for CRAN response >> >> On 15/12/2019 1:29 p.m., Tiago Olivoto wrote: >>> Dear all, >>> >>> I've submitted my package 'metan' to CRAN for the first time a few >>> weeks ago and received some suggestions to improve the code. After >>> fixing some bugs, I've resubmitted it on November 25, but I still >>> don't have any response and the package was not found in incoming/ >>> dir on CRAN cran ftp site. Since it is my first experience, I would >>> like to have an idea about how long the CRAN team usually decides >>> about a package submission. >>> >> >> If it is not in incoming/, something went wrong. The most common >> thing to go wrong is that the maintainer didn't respond to the >> confirmation message. That message looks like this for a >> resubmission. I assume first time submissions have a similar message: >> >>> Dear Duncan Murdoch >>> Someone has submitted the package rgl to CRAN. >>> You are receiving this email to confirm the submission as the >>> maintainer of this package. >>> To confirm the submission to CRAN, follow or copy & paste the >>> following link into your browser: >>> ... >> >> >> When you confirm submission, you'll get another message that looks >> like >> this: >> >>> [This was generated from CRAN.R-project.org/submit.html] >>> >>> The following package was uploaded to CRAN: >>> === >>> >>> Package Information: >>> Package: rgl >>> Version: 0.100.26 >> > ... >> >> After that, it goes into a queue for checking, and usually within a >> few days you'll be told about problems with it or it will be accepted >> to CRAN. (Sometimes you'll be told very quickly, if the automated >> checks find a problem.) >> >> Duncan Murdoch >> > > __ > 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
Re: [R-pkg-devel] RES: Time for CRAN response
On 15.12.2019 23:39, Duncan Murdoch wrote: On 15/12/2019 4:57 p.m., Tiago Olivoto wrote: Thank you for the response. As far I remember, I've responded that message by following the link and selecting "I have read the CRAN policies and would like to submit this package to CRAN" and " I have checked the submission using R CMD check --as-cran and a current version of r-devel, as mandated by the CRAN Repository Policy. (You could do so using the win-builder service at https://win-builder.r-project.org)", and then clicking on "upload package to CRAN" These same steps were followed in the first submission, but at that time I received the following message that was not received in the last submission. Dear maintainer, package metan_1.0.0.tar.gz has been auto-processed and is pending a manual inspection of this new CRAN submission. A CRAN team member will typically respond to you within the next 10 working days. Should I try to re-submit it again? Probably. I'd wait 24 hours, to see if someone from CRAN replies with more information. Thanks, Duncan, here we got: 1. I did not spot a request for help from Nov 25 in the many messsages we receive. That one has now been answered. 2. I do not see a submission fom Nov 25. Can you simply resubmit and make sure you click on the confirmation link? Best, Uwe Ligges Duncan Murdoch Best, Tiago Olivoto -Mensagem original- De: Duncan Murdoch Enviada em: domingo, 15 de dezembro de 2019 17:35 Para: tiagooliv...@gmail.com; r-package-devel@r-project.org Assunto: Re: [R-pkg-devel] Time for CRAN response On 15/12/2019 1:29 p.m., Tiago Olivoto wrote: Dear all, I've submitted my package 'metan' to CRAN for the first time a few weeks ago and received some suggestions to improve the code. After fixing some bugs, I've resubmitted it on November 25, but I still don't have any response and the package was not found in incoming/ dir on CRAN cran ftp site. Since it is my first experience, I would like to have an idea about how long the CRAN team usually decides about a package submission. If it is not in incoming/, something went wrong. The most common thing to go wrong is that the maintainer didn't respond to the confirmation message. That message looks like this for a resubmission. I assume first time submissions have a similar message: Dear Duncan Murdoch Someone has submitted the package rgl to CRAN. You are receiving this email to confirm the submission as the maintainer of this package. To confirm the submission to CRAN, follow or copy & paste the following link into your browser: ... When you confirm submission, you'll get another message that looks like this: [This was generated from CRAN.R-project.org/submit.html] The following package was uploaded to CRAN: === Package Information: Package: rgl Version: 0.100.26 > ... After that, it goes into a queue for checking, and usually within a few days you'll be told about problems with it or it will be accepted to CRAN. (Sometimes you'll be told very quickly, if the automated checks find a problem.) Duncan Murdoch __ 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
Re: [R-pkg-devel] RES: Time for CRAN response
On 15/12/2019 4:57 p.m., Tiago Olivoto wrote: Thank you for the response. As far I remember, I've responded that message by following the link and selecting "I have read the CRAN policies and would like to submit this package to CRAN" and " I have checked the submission using R CMD check --as-cran and a current version of r-devel, as mandated by the CRAN Repository Policy. (You could do so using the win-builder service at https://win-builder.r-project.org)", and then clicking on "upload package to CRAN" These same steps were followed in the first submission, but at that time I received the following message that was not received in the last submission. Dear maintainer, package metan_1.0.0.tar.gz has been auto-processed and is pending a manual inspection of this new CRAN submission. A CRAN team member will typically respond to you within the next 10 working days. Should I try to re-submit it again? Probably. I'd wait 24 hours, to see if someone from CRAN replies with more information. Duncan Murdoch Best, Tiago Olivoto -Mensagem original- De: Duncan Murdoch Enviada em: domingo, 15 de dezembro de 2019 17:35 Para: tiagooliv...@gmail.com; r-package-devel@r-project.org Assunto: Re: [R-pkg-devel] Time for CRAN response On 15/12/2019 1:29 p.m., Tiago Olivoto wrote: Dear all, I've submitted my package 'metan' to CRAN for the first time a few weeks ago and received some suggestions to improve the code. After fixing some bugs, I've resubmitted it on November 25, but I still don't have any response and the package was not found in incoming/ dir on CRAN cran ftp site. Since it is my first experience, I would like to have an idea about how long the CRAN team usually decides about a package submission. If it is not in incoming/, something went wrong. The most common thing to go wrong is that the maintainer didn't respond to the confirmation message. That message looks like this for a resubmission. I assume first time submissions have a similar message: Dear Duncan Murdoch Someone has submitted the package rgl to CRAN. You are receiving this email to confirm the submission as the maintainer of this package. To confirm the submission to CRAN, follow or copy & paste the following link into your browser: ... When you confirm submission, you'll get another message that looks like this: [This was generated from CRAN.R-project.org/submit.html] The following package was uploaded to CRAN: === Package Information: Package: rgl Version: 0.100.26 > ... After that, it goes into a queue for checking, and usually within a few days you'll be told about problems with it or it will be accepted to CRAN. (Sometimes you'll be told very quickly, if the automated checks find a problem.) Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] RES: Time for CRAN response
Thank you for the response. As far I remember, I've responded that message by following the link and selecting "I have read the CRAN policies and would like to submit this package to CRAN" and " I have checked the submission using R CMD check --as-cran and a current version of r-devel, as mandated by the CRAN Repository Policy. (You could do so using the win-builder service at https://win-builder.r-project.org)", and then clicking on "upload package to CRAN" These same steps were followed in the first submission, but at that time I received the following message that was not received in the last submission. > Dear maintainer, > > package metan_1.0.0.tar.gz has been auto-processed and is pending a manual > inspection of this new CRAN submission. A CRAN team member will typically > respond to you within the next 10 working days. Should I try to re-submit it again? Best, Tiago Olivoto -Mensagem original- De: Duncan Murdoch Enviada em: domingo, 15 de dezembro de 2019 17:35 Para: tiagooliv...@gmail.com; r-package-devel@r-project.org Assunto: Re: [R-pkg-devel] Time for CRAN response On 15/12/2019 1:29 p.m., Tiago Olivoto wrote: > Dear all, > > I've submitted my package 'metan' to CRAN for the first time a few > weeks ago and received some suggestions to improve the code. After > fixing some bugs, I've resubmitted it on November 25, but I still > don't have any response and the package was not found in incoming/ dir > on CRAN cran ftp site. Since it is my first experience, I would like > to have an idea about how long the CRAN team usually decides about a package > submission. > If it is not in incoming/, something went wrong. The most common thing to go wrong is that the maintainer didn't respond to the confirmation message. That message looks like this for a resubmission. I assume first time submissions have a similar message: > Dear Duncan Murdoch > Someone has submitted the package rgl to CRAN. > You are receiving this email to confirm the submission as the > maintainer of this package. > To confirm the submission to CRAN, follow or copy & paste the > following link into your browser: > ... When you confirm submission, you'll get another message that looks like this: > [This was generated from CRAN.R-project.org/submit.html] > > The following package was uploaded to CRAN: > === > > Package Information: > Package: rgl > Version: 0.100.26 > ... After that, it goes into a queue for checking, and usually within a few days you'll be told about problems with it or it will be accepted to CRAN. (Sometimes you'll be told very quickly, if the automated checks find a problem.) Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] No prebuilt vignette index
Remove the "inst" directory and don't use "--no-build-vignettes" in your
build command.
Iñaki
On Sun, 15 Dec 2019 at 21:45, Charith Karunarathna <
charith_karunarat...@sfu.ca> wrote:
>
>
> Hi Everyone,
>
>
> I wonder how to address the following NOTE that I am getting from the
> win-builder check.
>
>
> "
>
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: 'Charith Karunarathna '
>
> Package has a VignetteBuilder field but no prebuilt vignette index.
>
> "
>
>
>
> I am including a static PDF vignette to my package following the
> instructions at
> https://cran.r-project.org/web/packages/R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
>
>
>
> The .pdf.asis file (perfectphyloR.pdf.asis) is as follows:
>
>
> "
>
> %\VignetteIndexEntry{perfectphyloR: Reconstruct Perfect Phylogenies from
> DNA Sequence Data}
> %\VignetteEngine{R.rsp::asis}
>
> "
> For more details, these are the links for the repository and win-builder
> check:
>
> - Link for the package's github repository:
> https://github.com/cbhagya/perfectphyloR
> - Link for win-builder checks:
> https://win-builder.r-project.org/7d6SEV4IwMNL/00check.log
>
> I have no idea how to address the above NOTE. Can somebody help me fix
> this issue?
>
>
> Thank you!
>
>
> Charith.
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Iñaki Úcar
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] No prebuilt vignette index
Hi Everyone,
I wonder how to address the following NOTE that I am getting from the
win-builder check.
"
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Charith Karunarathna '
Package has a VignetteBuilder field but no prebuilt vignette index.
"
I am including a static PDF vignette to my package following the instructions
at
https://cran.r-project.org/web/packages/R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
The .pdf.asis file (perfectphyloR.pdf.asis) is as follows:
"
%\VignetteIndexEntry{perfectphyloR: Reconstruct Perfect Phylogenies from DNA
Sequence Data}
%\VignetteEngine{R.rsp::asis}
"
For more details, these are the links for the repository and win-builder check:
- Link for the package's github repository:
https://github.com/cbhagya/perfectphyloR
- Link for win-builder checks:
https://win-builder.r-project.org/7d6SEV4IwMNL/00check.log
I have no idea how to address the above NOTE. Can somebody help me fix this
issue?
Thank you!
Charith.
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Time for CRAN response
On 15/12/2019 1:29 p.m., Tiago Olivoto wrote: Dear all, I've submitted my package 'metan' to CRAN for the first time a few weeks ago and received some suggestions to improve the code. After fixing some bugs, I've resubmitted it on November 25, but I still don't have any response and the package was not found in incoming/ dir on CRAN cran ftp site. Since it is my first experience, I would like to have an idea about how long the CRAN team usually decides about a package submission. If it is not in incoming/, something went wrong. The most common thing to go wrong is that the maintainer didn't respond to the confirmation message. That message looks like this for a resubmission. I assume first time submissions have a similar message: Dear Duncan Murdoch Someone has submitted the package rgl to CRAN. You are receiving this email to confirm the submission as the maintainer of this package. To confirm the submission to CRAN, follow or copy & paste the following link into your browser: ... When you confirm submission, you'll get another message that looks like this: [This was generated from CRAN.R-project.org/submit.html] The following package was uploaded to CRAN: === Package Information: Package: rgl Version: 0.100.26 > ... After that, it goes into a queue for checking, and usually within a few days you'll be told about problems with it or it will be accepted to CRAN. (Sometimes you'll be told very quickly, if the automated checks find a problem.) Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Time for CRAN response
Dear all, I've submitted my package 'metan' to CRAN for the first time a few weeks ago and received some suggestions to improve the code. After fixing some bugs, I've resubmitted it on November 25, but I still don't have any response and the package was not found in incoming/ dir on CRAN cran ftp site. Since it is my first experience, I would like to have an idea about how long the CRAN team usually decides about a package submission. Best, Tiago Olivoto [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Large Data Package CRAN Preferences
On Sun, Dec 15, 2019 at 6:27 PM wrote: > Thanks for this information, and it makes sense to me. Is there a preferred > way to cache the data locally? Personally I like making an R package out of the data and hosting it in an "AdditionalRepository". This is quite easy with the help of the drat package. See https://journal.r-project.org/archive/2017/RJ-2017-026/RJ-2017-026.pdf for details of this approach. cheerio ralf __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Large Data Package CRAN Preferences
The R.cache package on CRAN provides can be used for this purpose. It
works on all platforms. Per CRAN Policies, it will prompt the user
(in an interactive session) whether they wish to use a persistent
cache folder, or to fall back to temporary one. For example,
> path <- R.cache::getCachePath(dirs = "MyDataPkg")
The R.cache package needs to create a directory that will hold cache
files. It is convenient to use '/home/hb/.cache/R/R.cache' because it
follows the standard on your operating system and it remains also
after restarting R. Do you wish to create the
'/home/hb/.cache/R/R.cache' directory? If not, a temporary directory
(/tmp/hb/RtmpvEgWIr/.Rcache) that is specific to this R session will
be used. [Y/n]:
> path
[1] "/home/hb/.cache/R/R.cache/MyDataPkg"
>
Once the user have accepted this, this folder is created and will be
available in all future R session. That is, next time they start R
there will be no prompt:
> path <- R.cache::getCachePath(dirs = "MyDataPkg")
> path
[1] "/home/hb/.cache/R/R.cache/MyDataPkg"
This will also be the case in non-interactive session. If that folder
does not exists in non-interactive session, then a temporary folder
will be used (= effectively making the cache lifetime equal to the
session lifetime). 'R CMD check' will always use a temporary cache
such that there is no memory between checks.
/Henrik
(disclaimer: I'm the author)
On Sun, Dec 15, 2019 at 9:27 AM wrote:
>
> Hi Uwe,
>
> Thanks for this information, and it makes sense to me. Is there a preferred
> way to cache the data locally?
>
> None of the ways that I can think to cache the data sound particularly good,
> and I wonder if I'm missing something. The ideas that occur to me are:
>
> 1. Download them into the package directory `path.package("datapkg")`, but
> that would require an action to be performed on package installation, and I'm
> unaware of any way to trigger an action on installation.
> 2. Have a user-specified cache directory (e.g.
> `options("datapkg_cache"="/my/cache/location")`), but that would require
> interaction with every use. (Not horrible, but it will likely significantly
> increase the number of user issues with the package.)
> 3. Have a user-specified cache directory like #2, but have it default to
> somewhere in their home directory like `file.path(Sys.getenv("HOME"),
> "datapkg_cache")` if they have not set the option.
>
> To me #3 sounds best, but I'd like to be sure that I'm not missing something.
>
> Thanks,
>
> Bill
>
> -Original Message-
> From: Uwe Ligges
> Sent: Sunday, December 15, 2019 11:54 AM
> To: b...@denney.ws; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Large Data Package CRAN Preferences
>
> Ideally yoiu wpuld host the data elsewhere and submit a CRAN package that
> allows users to easily get/merge/aggregate the data.
>
> Best,
> Uwe Ligges
>
>
>
> On 12.12.2019 20:55, b...@denney.ws wrote:
> > Hello,
> >
> >
> >
> > I have two questions about creating data packages for data that will
> > be updated and in total are >5 MB in size.
> >
> >
> >
> > The first question is:
> >
> >
> >
> > In the CRAN policy, it indicates that packages should be ?5 MB in size
> > in general. Within a package that I'm working on, I need access to
> > data that are updated approximately quarterly, including the
> > historical datasets (specifically, these are the SDTM and CDASH
> > terminologies in https://evs.nci.nih.gov/ftp1/CDISC/SDTM/Archive/).
> >
> >
> >
> > Current individual data updates are approximately 1 MB when
> > individually saved as .RDS, and the total current set is about 20 MB.
> > I think that the preferred way to generate these packages since there
> > will be future updates is to generate one data package for each update
> > and then have an umbrella package that will depend on each of the
> > individual data update packages.
> > That seems like it will minimize space requirements on CRAN since old
> > data will probably never need to be updated (though I will need to access
> > it).
> >
> >
> >
> > Is that an accurate summary of the best practice for creating these as
> > a data package?
> >
> >
> >
> > And a second question is:
> >
> >
> >
> > Assuming the best practice is the one I described above, the typical
> > need will be to combine the individual historical datasets for local
> > use. An initial test of the time to combine the data indicates that
> > it would take about 1 minute to do, but after combination, the result
> > could be loaded faster. I'd like to store the combined dataset
> > locally with the umbrella package. I believe that it is considered
> > poor form to write within the library location for a package except during
> > installation.
> >
> >
> >
> > What is the best practice for caching the resulting large dataset
> > which is locally-generated?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Bill
> >
> >
> > [[alternative HTML version deleted]]
> >
> >
Re: [R-pkg-devel] Large Data Package CRAN Preferences
Hi Uwe,
Thanks for this information, and it makes sense to me. Is there a preferred
way to cache the data locally?
None of the ways that I can think to cache the data sound particularly good,
and I wonder if I'm missing something. The ideas that occur to me are:
1. Download them into the package directory `path.package("datapkg")`, but that
would require an action to be performed on package installation, and I'm
unaware of any way to trigger an action on installation.
2. Have a user-specified cache directory (e.g.
`options("datapkg_cache"="/my/cache/location")`), but that would require
interaction with every use. (Not horrible, but it will likely significantly
increase the number of user issues with the package.)
3. Have a user-specified cache directory like #2, but have it default to
somewhere in their home directory like `file.path(Sys.getenv("HOME"),
"datapkg_cache")` if they have not set the option.
To me #3 sounds best, but I'd like to be sure that I'm not missing something.
Thanks,
Bill
-Original Message-
From: Uwe Ligges
Sent: Sunday, December 15, 2019 11:54 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Large Data Package CRAN Preferences
Ideally yoiu wpuld host the data elsewhere and submit a CRAN package that
allows users to easily get/merge/aggregate the data.
Best,
Uwe Ligges
On 12.12.2019 20:55, b...@denney.ws wrote:
> Hello,
>
>
>
> I have two questions about creating data packages for data that will
> be updated and in total are >5 MB in size.
>
>
>
> The first question is:
>
>
>
> In the CRAN policy, it indicates that packages should be ?5 MB in size
> in general. Within a package that I'm working on, I need access to
> data that are updated approximately quarterly, including the
> historical datasets (specifically, these are the SDTM and CDASH
> terminologies in https://evs.nci.nih.gov/ftp1/CDISC/SDTM/Archive/).
>
>
>
> Current individual data updates are approximately 1 MB when
> individually saved as .RDS, and the total current set is about 20 MB.
> I think that the preferred way to generate these packages since there
> will be future updates is to generate one data package for each update
> and then have an umbrella package that will depend on each of the individual
> data update packages.
> That seems like it will minimize space requirements on CRAN since old
> data will probably never need to be updated (though I will need to access it).
>
>
>
> Is that an accurate summary of the best practice for creating these as
> a data package?
>
>
>
> And a second question is:
>
>
>
> Assuming the best practice is the one I described above, the typical
> need will be to combine the individual historical datasets for local
> use. An initial test of the time to combine the data indicates that
> it would take about 1 minute to do, but after combination, the result
> could be loaded faster. I'd like to store the combined dataset
> locally with the umbrella package. I believe that it is considered
> poor form to write within the library location for a package except during
> installation.
>
>
>
> What is the best practice for caching the resulting large dataset
> which is locally-generated?
>
>
>
> Thanks,
>
>
>
> Bill
>
>
> [[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
Re: [R-pkg-devel] r2sundials submission failure
Have you tried to write to CRAN@... and ask if thirs party software can be installed on CRAN? Best, Uwe Ligges On 11.12.2019 10:39, Serguei Sokol wrote: Hi, I have tried to submit my new package https://github.com/sgsokol/r2sundials to CRAN but submission seems to be dismissed. The package needs a third part software https://computing.llnl.gov/projects/sundials/cvodes so it cannot be built on CRAN automatically. I explained this (and how the package was tested by myself) in the submitter's comment (cf. hereafter) and second time in the reply to all (as was requested) to automatic message from CRAN announcing the building failure but to no avail. The submission was done on November 25, more than two weeks later I still don't have any response and the package is no more in incoming/ dir on cran ftp site. I conclude that this submission is dismissed. My question is: what can be reasonably done to make a package like this (i.e. depending on third part software not available on CRAN) to be accepted? Or may be the current policy: all new package must automatically build. Period. In my case it can imply ~20 MB additional space (source code + libs). Thanks in advance for any hint. Serguei. Submitter's comment: Dear CRAN team, I submit package r2sundials which depends on a third part software from https://computing.llnl.gov/projects/sundials/cvodes This is the reason for which it will not automatically build on your test systems. But on my side, I could successfully run 'R CMD check --as-cran' on Linux (R-3.6.1, gcc8), MacOS Catalina (R-3.6.1, Apple clang-1100.0.33.12) and Windows 10 (R-devel r77430, gcc-4.9.3). If you wish, I can send you reports from these runs. Even if it is improbable, but if you decide to run such checks manually by your self, installation instructions are available on https://github.com/sgsokol/r2sundials Moreover, winbuilder signals: Possibly mis-spelled words in DESCRIPTION: CVODES (3:34) Hindmarsh (9:803) Rcpp (3:8, 9:285) al (9:816) cvodes (9:47) et (9:813) rmumps (9:501) These all are false positives designating software, R packages and bibliographic reference. __ 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
Re: [R-pkg-devel] Large Data Package CRAN Preferences
Ideally yoiu wpuld host the data elsewhere and submit a CRAN package that allows users to easily get/merge/aggregate the data. Best, Uwe Ligges On 12.12.2019 20:55, b...@denney.ws wrote: Hello, I have two questions about creating data packages for data that will be updated and in total are >5 MB in size. The first question is: In the CRAN policy, it indicates that packages should be ?5 MB in size in general. Within a package that I'm working on, I need access to data that are updated approximately quarterly, including the historical datasets (specifically, these are the SDTM and CDASH terminologies in https://evs.nci.nih.gov/ftp1/CDISC/SDTM/Archive/). Current individual data updates are approximately 1 MB when individually saved as .RDS, and the total current set is about 20 MB. I think that the preferred way to generate these packages since there will be future updates is to generate one data package for each update and then have an umbrella package that will depend on each of the individual data update packages. That seems like it will minimize space requirements on CRAN since old data will probably never need to be updated (though I will need to access it). Is that an accurate summary of the best practice for creating these as a data package? And a second question is: Assuming the best practice is the one I described above, the typical need will be to combine the individual historical datasets for local use. An initial test of the time to combine the data indicates that it would take about 1 minute to do, but after combination, the result could be loaded faster. I'd like to store the combined dataset locally with the umbrella package. I believe that it is considered poor form to write within the library location for a package except during installation. What is the best practice for caching the resulting large dataset which is locally-generated? Thanks, Bill [[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
