Merge pull request #22 from EvolEcolGroup/dev

cran submission

.Rbuildignore

@@ -13,3 +13,5 @@ ci_dependencies
 ^codecov.yml
 ^data-raw$
 .covrignore
+^doc$
+^Meta$

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,28 @@
+<!-- This CODE_OF_CONDUCT.md is adapted from the same document in the tidyverse package -->
+
+
+# Contributor Code of Conduct
+
+As contributors and maintainers of this project, we pledge to respect all people who 
+contribute through reporting issues, posting feature requests, updating documentation,
+submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for
+everyone, regardless of level of experience, gender, gender identity and expression,
+sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.
+
+Examples of unacceptable behavior by participants include the use of sexual language or
+imagery, derogatory comments or personal attacks, trolling, public or private harassment,
+insults, or other unprofessional conduct.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments,
+commits, code, wiki edits, issues, and other contributions that are not aligned to this 
+Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed 
+from the project team.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by 
+opening an issue or contacting one or more of the project maintainers.
+
+This Code of Conduct is adapted from the Contributor Covenant 
+(https://www.contributor-covenant.org), version 1.0.0, available at 
+https://contributor-covenant.org/version/1/0/0/.

.github/CONTRIBUTING.md

@@ -0,0 +1,104 @@
+# Contributing to tidysdm
+
+
+This document outlines how to contribute to the development of `tidysdm`. The
+package is maintained on a voluntary basis, so help is always appreciated. 
+
+## The basic process of contributing
+
+Development work for `tidysdm` occurs in the `dev` branch. So, if you want to
+propose any changes, you should work on `dev`. Start by forking the project
+onto your github repository, make the changes directly in your fork (either in
+the `dev` branch, or make a custom branch). After updating all the documentation
+and checking that all tests pass (see below), start a Pull Request. Your proposed
+changes will be reviewed, and you might be asked to fix/improve your code. This
+can be an iterative process, requiring a few rounds of revision depending on
+the complexity of the code.
+
+Functions should be documented using [`roxygen`](https://cran.r-project.org/web/packages/roxygen2/vignettes/roxygen2.html).
+If any of your changes affects the documentation , you should rebuild it.
+From the root directory of the package, simply run:
+
+```
+devtools::document()
+```
+
+If you implemented a new functionality, or patched a bug, you should consider 
+whether you should add an appropriate unit test. `tidysdm` uses the `testthat` 
+framework for unit tests. You should make sure that tests work with :
+```
+devtools::test()
+```
+
+Finally, before you submit a push request, you should check that your changes 
+don't break the build. You can do that with `check`, which also builds the 
+vignette and runs the tests.:
+```
+devtools::check()
+```
+
+Make sure that you have resolved all warnings and notes raised by
+`devtools::check()`!
+
+Once you have followed **those 3 steps**, you are ready to make your Pull Request.
+Your changes will go through automatic continuous integration, which will check
+the impact of those changes on multiple platforms. If everything goes well, you
+will see a green tick on your submission.
+
+## Fixing typos
+
+If you spot typos, spelling mistakes, or grammatical errors in the documentation,
+you should fix them directly in the file that describes the function. This is the
+`.R` file in the `R` directory, NOT the `.Rd` file in the `man` directory. `.Rd`
+files are automatically generated by `roxygen2` and should not be edited by hand.
+We recommend that you study first how 
+[roxygen2 comments](https://roxygen2.r-lib.org/articles/roxygen2.html) work. 
+
+## Functional changes
+
+If you want to make a change that impacts the functioning of `tidysdm`,
+it's a good idea to first file an issue 
+explaining what you have in mind. If the change is meant to fix a bug, then  
+add a minimal 
+[reprex](https://www.tidyverse.org/help/#reprex). 
+
+A good reprex is also the
+perfect starting point for writing a unit test, which should accompany any
+functional change in the code. Unit tests are also essential when fix bugs, so
+that you can both demonstrate that the fix work, and prevent future changes
+from undoing your work. For unit testing, we use `testthat`; you will find tests under
+`tests`, with a file dedicated to each function, following the convention 
+`test_my_function.R` for naming files.
+
+Ideally, the body of your Pull Request will include the phrase `Fixes #issue-number`,
+where `issue_number` is the number on Github. In this way, your Pull Request
+will be automatically linked to the issue, and the issue will be closed when
+the Pull Request is merged in.
+
+For user-facing changes, add a bullet to the top of `NEWS.md` 
+(i.e. just below the first header). Follow the style described 
+in <https://style.tidyverse.org/news.html>.
+
+### Code style
+
+New code should follow the tidyverse [style guide](https://style.tidyverse.org). 
+You can use the [styler](https://CRAN.R-project.org/package=styler) package 
+to apply these styles, but please don't restyle code that has nothing to do with your PR.
+
+Lot's of commenting in the code helps mantainability; so, if in doubt, always
+add an explanation to your new code.
+
+As discussed above, we use [roxygen2](https://cran.r-project.org/package=roxygen2), with [Markdown syntax](https://roxygen2.r-lib.org/articles/rd-formatting.html), for documentation.  
+
+We use [testthat](https://cran.r-project.org/package=testthat) for unit tests. 
+Contributions that change functionality should always include test cases. Our
+continuous integration checks that the Pull Request does not reduce test coverage.
+When creating tests, try to make use built-in datasets, rather than adding data
+files to the package.
+
+## Code of Conduct
+         
+Please note that the tidyverse project is released with a
+[Contributor Code of Conduct](CODE_OF_CONDUCT.md). By contributing to this
+project you agree to abide by its terms.
+

.github/workflows/R-CMD-check.yaml

@@ -44,13 +44,13 @@ jobs:
           extra-packages: any::rcmdcheck
           needs: check
 
-      - name: Get dev terra and pastclim
+#      - name: Get dev terra and pastclim
        # if: matrix.config.os == 'macos-latest' || ${{ github.base_ref == 'dev' }} || ${{ github.ref_name == 'dev' }}
-        run: |
-          install.packages('terra', repos='https://rspatial.r-universe.dev')
-          install.packages('devtools')
-          devtools::install_github("EvolEcolGroup/pastclim", ref="dev")
-        shell: Rscript {0}
+#        run: |
+#          install.packages('terra', repos='https://rspatial.r-universe.dev')
+#          install.packages('devtools')
+#          devtools::install_github("EvolEcolGroup/pastclim", ref="dev")
+#        shell: Rscript {0}
 
       - uses: r-lib/actions/check-r-package@v2
         with:

.github/workflows/pkgdown.yaml

@@ -35,12 +35,12 @@ jobs:
           extra-packages: any::pkgdown, local::.
           needs: website
 
-      - name: Get dev terra and pastclim
-        run: |
-          install.packages('terra', repos='https://rspatial.r-universe.dev')
-          install.packages('devtools')
-          devtools::install_github("EvolEcolGroup/pastclim", ref="dev")
-        shell: Rscript {0}
+#      - name: Get dev terra and pastclim
+#        run: |
+#          install.packages('terra', repos='https://rspatial.r-universe.dev')
+#          install.packages('devtools')
+#          devtools::install_github("EvolEcolGroup/pastclim", ref="dev")
+#        shell: Rscript {0}
 
       - name: Build site
         run: pkgdown::build_site_github_pages(new_process = FALSE, install = FALSE)

.github/workflows/test-coverage.yaml

@@ -31,12 +31,12 @@ jobs:
           extra-packages: any::covr
           needs: coverage
 
-      - name: Get dev terra and pastclim
-        run: |
-          install.packages('terra', repos='https://rspatial.r-universe.dev')
-          install.packages('devtools')
-          devtools::install_github("EvolEcolGroup/pastclim", ref="dev")
-        shell: Rscript {0}
+#      - name: Get dev terra and pastclim
+#        run: |
+#          install.packages('terra', repos='https://rspatial.r-universe.dev')
+#          install.packages('devtools')
+#          devtools::install_github("EvolEcolGroup/pastclim", ref="dev")
+#        shell: Rscript {0}
 
       - name: Test coverage
         run: covr::codecov(type="all")

.gitignore

@@ -1,6 +1,9 @@
 .Rproj.user
+*.Rproj
 .Rhistory
 .RData
 .Ruserdata
 inst/doc
 docs
+/doc/
+/Meta/

DESCRIPTION

@@ -1,11 +1,16 @@
 Package: tidysdm
-Title: Species Distribution Models with tidymodels
-Version: 0.9.1
+Title: Species Distribution Models with Tidymodels
+Version: 0.9.2
 Authors@R: c(
     person("Michela", "Leonardi", role = "aut"),
     person("Margherita", "Colucci", role = "aut"),
     person("Andrea", "Manica", , "[email protected]", role = c("aut", "cre")))
-Description: Fit Species Distribution Models using the tidymodels framework, as described
+Description: Fit species distribution models (SDMs) using the 'tidymodels' framework, 
+  which provides a standardised interface to define models and process their 
+  outputs. 'tidysdm' expands 'tidymodels' by providing methods for spatial objects,
+  as well as a number of specialised functions to process presences and pseudoabsences
+  for contemporary and palaeo datasets. The full 
+  functionalities of the package are described
   in Leonardi et al. (2023) <doi:10.1101/2023.07.24.550358>.
 License: AGPL (>= 3)
 Encoding: UTF-8
@@ -48,14 +53,16 @@ Suggests:
     kernlab,
     knitr,
     overlapping,
-    pastclim,
+    pastclim (>= 2.0.0),
     ranger,
     readr,
     rmarkdown,
+    spelling,
     stacks,
     testthat (>= 3.0.0),
     tidyterra,
-    xgboost
+    xgboost,
+    V8
 VignetteBuilder: knitr
 Config/testthat/edition: 3
 LazyData: true

NAMESPACE

@@ -57,7 +57,6 @@ export(check_splits_balance)
 export(control_ensemble_bayes)
 export(control_ensemble_grid)
 export(control_ensemble_resamples)
-export(date2ybp)
 export(dist_pres_vs_bg)
 export(explain_tidysdm)
 export(feature_classes)
@@ -98,7 +97,6 @@ export(tss)
 export(tss_max)
 export(tss_max_vec)
 export(y2d)
-export(ybp2date)
 import(recipes)
 import(spatialsample)
 import(tidymodels)

NEWS.md

@@ -1,3 +1,7 @@
+# `tidysdm` 0.9.2
+
+* Release on CRAN
+
 # `tidysdm` 0.9.1
 
 * Add a `spatial_recipe` class. This is a BREAKING change that makes previously

R/add_member.R

@@ -2,7 +2,8 @@
 #'
 #' This function adds member(s) to a [simple_ensemble()] object, taking the
 #' best member from each workflow provided. It is possible to pass individual
-#' `tune_results` objects from a tuned `workflow`, or a [workflowsets::workflow_set()].
+#' `tune_results` objects from a tuned `workflow`, or a
+#'  [workflowsets::workflow_set()].
 #'
 #' @param x a [simple_ensemble] to which member(s) will be added
 #' @param member a  `tune_results`, or a [`workflowsets::workflow_set`]
@@ -14,60 +15,64 @@
 
 # Note that `add_member` is tested in `test_simple_ensemble.R`
 
-add_member <- function (x, member, ...) {
+add_member <- function(x, member, ...) {
   UseMethod("add_member", object = member)
 }
 
 #' @rdname add_member
 #' @export
-add_member.default <- function(x, member, ...){
+add_member.default <- function(x, member, ...) {
   stop("no method available for this object type")
 }
 
 #' @param id the name to be given to this workflow in the `wflow_id` column.
 #' @rdname add_member
 #' @export
-add_member.tune_results <- function(x, member, metric = NULL, id=NULL, ...){
+add_member.tune_results <- function(x, member, metric = NULL, id = NULL, ...) {
   # set the metric if the simple ensemble is empty (and thus has no metric)
-  if (is.null(attr(x,"best_metric"))){
-    attr(x,"best_metric") <- utils::getFromNamespace("choose_metric", "tune")(metric, member)
+  if (is.null(attr(x, "best_metric"))) {
+    attr(x, "best_metric") <- utils::getFromNamespace(
+      "choose_metric",
+      "tune"
+    )(metric, member)
   }
 
   # if metric is NULL
-  if (is.null(metric)){
+  if (is.null(metric)) {
     # use the metric from the simple ensemble
-    metric <- attr(x,"best_metric")
+    metric <- attr(x, "best_metric")
   } else {
-    if (metric!=attr(x,"best_metric")){
+    if (metric != attr(x, "best_metric")) {
       stop("the requested metric is not the same as the one previously used in x")
     }
   }
 
   # use name of object as id if we don't have one
-  if (is.null(id)){
-    id <-deparse(substitute(member))
+  if (is.null(id)) {
+    id <- deparse(substitute(member))
   }
   # check that id is unique
-  if (id %in% x$wflow_id){
+  if (id %in% x$wflow_id) {
     stop("x already has a member with the same name, provide an alternative name")
   }
 
   # get the best config, metric, etc.
-  best_config <- tune::select_best(member,metric)$.config
+  best_config <- tune::select_best(member, metric)$.config
   best_metrics <- tune::collect_metrics(member) %>%
-    dplyr::filter(.data$.config ==best_config) %>%
+    dplyr::filter(.data$.config == best_config) %>%
     dplyr::select(dplyr::all_of(c(".metric", "mean", "std_err", "n"))) %>%
-    dplyr::mutate(wflow_id=id, .before=dplyr::all_of(c(".metric")))
+    dplyr::mutate(wflow_id = id, .before = dplyr::all_of(c(".metric")))
   # now check that metrics are the same as in best_metrics
-  if (!is.null(attr(x,"metrics"))){
-    if(!all(attr(x,"metrics")%in%best_metrics$.metric)){
+  if (!is.null(attr(x, "metrics"))) {
+    if (!all(attr(x, "metrics") %in% best_metrics$.metric)) {
       stop("x and member were not evaluated for the same metrics")
     }
   } else {
-    attr(x,"metrics")<-best_metrics$.metric
+    attr(x, "metrics") <- best_metrics$.metric
   }
   # subset best metrics to just the metrics used in the ensemble
-  best_metrics <- best_metrics %>% dplyr::filter(.data$.metric %in% attr(x,"metrics"))
+  best_metrics <- best_metrics %>%
+    dplyr::filter(.data$.metric %in% attr(x, "metrics"))
 
   best_fit <- tune::fit_best(member, metric = metric)
 
@@ -83,9 +88,9 @@ add_member.tune_results <- function(x, member, metric = NULL, id=NULL, ...){
 #' @rdname add_member
 #' @export
 add_member.workflow_set <- function(x, member, metric = NULL, ...) {
-  for (i_wflow in member$wflow_id){
+  for (i_wflow in member$wflow_id) {
     this_res <- workflowsets::extract_workflow_set_result(member, id = i_wflow)
-    x <- x %>% add_member(this_res, metric=metric, id = i_wflow)
+    x <- x %>% add_member(this_res, metric = metric, id = i_wflow)
   }
   x
 }