pkgcheck results - main

[github-actions]

Checks for stochLAB (v1.1.3)

git hash: c109d2ec

• ✔️ Package is already on CRAN.
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 75.9%.
• ✖️ Some goodpractice linters failed.
• ✖️ Statistical standards should be documented in most package files, yet are mostly only documented in one file.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL (>= 3)

[github-actions]

Checks for stochLAB (v1.1.3)

git hash: 24554d77

• ✔️ Package is already on CRAN.
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 75.9%.
• ✖️ Some goodpractice linters failed.
• ✖️ Statistical standards should be documented in most package files, yet are mostly only documented in one file.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL (>= 3)

[github-actions]

Checks for stochLAB (v1.1.3)

git hash: 91215ac2

• ✔️ Package is already on CRAN.
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 75.9%.
• ✖️ Some goodpractice linters failed.
• ✖️ Statistical standards should be documented in most package files, yet are mostly only documented in one file.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL-3

[github-actions]

Checks for stochLAB (v1.1.3)

git hash: 81129fda

• ✔️ Package is already on CRAN.
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 75.9%.
• ✖️ Some goodpractice linters failed.
• ✖️ Statistical standards should be documented in most package files, yet are mostly only documented in one file.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL-3

[maelle]

@grwhumphries I get the same results locally.

reparing: rcmdcheck

── stochLAB 1.1.3 ──────────────────────────────────────────────────────────────────────────────────────────

✔ Package is already on CRAN.
✔ has a 'codemeta.json' file.
✔ has a 'contributing' file.
✔ uses 'roxygen2'.
✔ 'DESCRIPTION' has a URL field.
✔ 'DESCRIPTION' has a BugReports field.
✔ Package has at least one HTML vignette
✔ All functions have examples.
✔ Package has continuous integration checks.
✔ Package coverage is 75.9%.
✖ Some goodpractice linters failed.
✖ Statistical standards should be documented in most package files, yet are mostly only documented in one file.
✔ R CMD check found no errors.
✔ R CMD check found no warnings.

ℹ Current status:
✖ This package is not ready to be submitted.


── git ──

• HEAD: 81129fda
• Default branch: main
• Number of commits: 132
• First commit: 15-07-2021
• Number of authors: 2


── rOpenSci Statistical Standards ──

ℹ The package is in the following 1 category:
• Exploratory Data Analysis

ℹ Compliance with rOpenSci statistical standards:
✖ All applicable standards [v0.2.0] have been documented in this package (80 complied with; 36 N/A standards)

── Package Structure ──

ℹ Package uses the following languages:
• R: 100%

ℹ Package has
• 4 authors.
• 1 vignette.
• 10 internal data files.
• 12 imported packages.
• 31 exported functions (median 22 lines of code).
• 56 non-exported functions (median 26 lines of code).
• 6 parameters per function (median).

── Package statistics ──

                    measure     value percentile noteworthy
1                   files_R      31.0       89.4           
4           files_vignettes       1.0       61.4           
5               files_tests      32.0       97.6           
6                     loc_R    2176.0       83.5           
7             loc_vignettes     324.0       63.9           
8                 loc_tests     948.0       82.3           
9             num_vignettes       1.0       58.4           
10          data_size_total 4622918.0       99.7       TRUE
11         data_size_median    2018.0       67.9           
12                  n_fns_r      87.0       71.3           
13         n_fns_r_exported      31.0       78.5           
14     n_fns_r_not_exported      56.0       68.8           
15         n_fns_per_file_r       1.7       30.7           
16        num_params_per_fn       6.0       77.3           
17             loc_per_fn_r      24.0       67.8           
18         loc_per_fn_r_exp      22.0       50.5           
19     loc_per_fn_r_not_exp      26.0       73.3           
20         rel_whitespace_R      26.8       89.4           
21 rel_whitespace_vignettes      20.4       45.7           
22     rel_whitespace_tests      15.0       75.9           
23      doclines_per_fn_exp      51.0       63.8           
24  doclines_per_fn_not_exp       0.0        0.0       TRUE
25     fn_call_network_size     157.0       84.6           

ℹ Package network diagram is at [/home/maelle/.cache/R/pkgcheck/static/stochLAB_pkgstats81129fda.html].


── goodpractice ──

── GP stochLAB ─────────────────────────────────────────────────────────────────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 75% of code
    lines are covered by test cases.

    R/band_crm.R:187:NA
    R/band_crm.R:188:NA
    R/band_crm.R:189:NA
    R/band_crm.R:190:NA
    R/band_crm.R:195:NA
    ... and 374 more lines

  ✖ write short and simple functions. These functions have high cyclomatic complexity
    (>50): validate_inputs (99). You can make them easier to reason about by encapsulating
    distinct steps of your function into subfunctions.
  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor
    windows that are about 80 characters wide. Try make your lines shorter than 80 characters

    data-raw/band_spreadsheet_data.R:46:81
    data-raw/band_spreadsheet_data.R:59:81
    data-raw/band_spreadsheet_data.R:60:81
    data-raw/band_spreadsheet_data.R:62:81
    data-raw/band_spreadsheet_data.R:63:81
    ... and 399 more lines

  ✖ avoid sapply(), it is not type safe. It might return a vector, or a list, depending
    on the input data. Consider using vapply() instead.

    R/DayLength.r:26:18
    R/sample_turbine_mCRM.R:101:30

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...), 1:NROW(...) and 1:NCOL(...)
    expressions. They are error prone and result 1:0 if the expression on the right hand side is
    zero. Use seq_len() or seq_along() instead.

    R/generate_rotor_grids.R:149:12
    R/generate_rotor_grids.R:161:19
    R/sample_params.r:159:14
    R/sample_params.r:219:12
    R/sample_turbine_mCRM.R:93:13
    ... and 1 more lines

  ✖ not import packages as a whole, as this can cause name clashes between the imported
    packages. Instead, import only the specific functions you need.
──────────────────────────────────────────────────────────────────────────────────────────────────────────── 
── Package Versions ──

  pkgstats: 0.2.0.58
  pkgcheck: 0.1.2.193
  srr: 0.1.4.8

@mpadge:

• When this package was peer-reviewed, was there no requirement on the standards being documented in several files? How to handle such cases: should the pkgcheck's workflow be ran for a given "edition" of the standards, should the package repo stop running pkgcheck?
• Shouldn't data-raw be excluded from the goodpractice checks?

@grwhumphries some of the goodpractice flags might be good (and rather simple) to fix, but I think that's your choice at this stage. 😸

[mpadge]

Thanks for asking @maelle. That is indeed a good question which unfortunately for the moment has a potentially unsatisfying answer of there being no way of running workflows for any given edition of standards. Options for doing that were discussed extensively, with the decision that it's simply too complex. There are indeed different versions of standards, although in effect currently only v0.2.0. We envision future increments in that, and packages can then optionally update compliance. But nothing there should effect pkgcheck results, which we endeavour to keep independent of any details in standards themselves. The check for most standards being documented in one file was simply something that was added long after ropensci/software-review#551.

@grwhumphries This does unfortunately mean that passing this check would require you to update your compliance statements by moving from main file https://github.com/MarineScotlandScience/stochLAB/blob/main/R/srr-stats-standards.R to more precise locations where these are actually addressed. Note there are two mechanisms at work here:

1. A check that standards compliance statements are sufficiently dispersed throughout the code base; and
2. A check that the actual text of standards has not been simply copy-pasted, but has been extensively modified.

Your package is currently failing the first of these, which I think means that the second isn't even being called. I suspect that once you fix the first, you may start to see the second check then also failing. sorry for any inconvenience here, and please let me know if you've got any questions.

[grwhumphries]

Hi @maelle and @mpadge - I see what you're getting at with the srr-stats-standards. This process definitely changed since we first set up this package and will certainly cause a massive delay to getting any further with the issue of getting this on to ROpenSci.

How does that work when you've got multiple instances of some of these things. For example, #' @srrstats {G2.4a} explicit conversion to integer via as.integer() - there will be an extensive number of places throughout the code where that standard is met - does one have to put "@srrstats {G2.4a}" at every instance of "as.integer()"?

Also, when extensively modifying each of these, would that actually mean stating something like "on line 295 we use as.integer explicitly"? If so, wouldn't that be simply become busy work?

And with the extensive number of standards that need to be met, where does one draw the line as to it becoming a barrier to implementation? Most people don't have that kind of time on their hands (particularly those of us with kids who cannot spend our spare time tinkering in R packages, etc...) - especially when some of these R packages are quite large.

[mpadge]

Thanks for your concerns @grwhumphries, all of which we do indeed take very seriously. We have long been aware that we may well have set the bar for stats submissions too high, and will be endeavouring from here on to ensure that any and all future developments only make things easier and not harder. More specifically in response to your comments:

How does that work when you've got multiple instances of some of these things. For example, #' @srrstats {G2.4a} explicit conversion to integer via as.integer() - there will be an extensive number of places throughout the code where that standard is met - does one have to put "@srrstats {G2.4a}" at every instance of "as.integer()"?

No, we don't generally expect standard to be repeated for every instance of simple and generic forms like that, although we do generally expect standards to be repeated throughout code. In that case, for example, I'd suggest something like one repeat of {G2.4a} per file.

Also, when extensively modifying each of these, would that actually mean stating something like "on line 295 we use as.integer explicitly"? If so, wouldn't that be simply become busy work?

The simpler the standard, the simpler the response may and generally should be. For general things like G2.4a, compliance statements need only be reduced form of standards, so something like:

G4.2a as.integer() is used throughout.

And with the extensive number of standards that need to be met, where does one draw the line as to it becoming a barrier to implementation? Most people don't have that kind of time on their hands (particularly those of us with kids who cannot spend our spare time tinkering in R packages, etc...) - especially when some of these R packages are quite large.

Very true, and as said at the outset, an issue we do take seriously. I guess what we could, and arguably should, do from our side would be to extend the srr package to add helper functions to automatically replicate and insert repeated versions of simple standards like that. So you could do something like:

txt <- "@srrstats {G4.2a} `as.integer()` is used throughout
srr_insert_statement("G4.2a", txt)

That would search for all usages of as.integer() applied to a function parameter, and insert that compliance statement in the function docs. That would, however, entail quite a lot of work on our side, as well as requiring some way of assessing whether the specified text statement is actually sufficiently complied with. Moreover, it is often easier these days to automate such processes within developers' own IDEs, and so that kind of extension is not likely at this time to be implemented, alas.

---

Note regardless that pkgcheck checks are required to pass for review to start. In your case, you've already passed, and so may continue to develop as you desire and are able, and simply ignore failing pkgcheck results until you have time to fix them. I'm not sure what your visions and plans are for reconciling ropensci/stochLAB against MarineScotlandScience/stochLAB, but as always, am happy to help further any way I can - just let me know.

[github-actions]

Checks for stochLAB (v1.1.4)

git hash: f16dab5b

• ✔️ Package is already on CRAN.
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 75.7%.
• ✖️ Statistical standards should be documented in most package files, yet are mostly only documented in one file.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.
• 👀 Some goodpractice linters failed.
• 👀 Function names are duplicated in other packages

Important: All failing checks above must be addressed prior to proceeding

(Checks marked with 👀 may be optionally addressed.)

Package License: GPL-3