Antagomir - #335

Ok I manually checked these and they seem sensible.

I was thinking about the number of Imports and of course 17 is better than 21 but the difference is not drastic. Additionally:

Moving ISOweek from Imports to Suggests breaks the following test:

Error (test_04_get.R:86:3): weekly dataset download (dissemination API) works correctly
Error: Package "ISOweek" is required for converting weekly Eurostat data into dates but is not installed.
Install it with: install.packages("ISOweek")
Backtrace:
    ▆
 1. ├─testthat::expect_match(...) at test_04_get.R:86:3

Moving classInt from Imports to Suggests produces the following message when building:

 ℹ Loading eurostat
✖ cut_to_classes.R:12: @details refers to un-installed package classInt.
✖ cut_to_classes.R:25: @seealso refers to un-installed package classInt.
✖ In topic 'cut_to_classes': @inheritParams failed because classInt is not installed.
Writing cut_to_classes.Rd
Documentation completed

and breaks the following test:

Error (test_07_misc.R:42:3): cut_to_classes works
Error: Package "classInt" is required for automatic class intervals in cut_to_classes() but is not installed.
Install it with: install.packages("classInt")
Backtrace:
    ▆
 1. ├─testthat::expect_visible(cut_to_classes(dataset$values)) at test_07_misc.R:42:3

Actually countrycode will anyway be loaded since eurostat package imports the regions package which imports countrycode so moving it to suggests in eurostat lowers the number but still ensures that countrywide is actually installed...

Actually I noticed that functions from these packages are not probably used if the user just uses default parameters for eurostat function calls, so making them optional should not result in constant nagging. I would still suggest that Claude reverses commit 72a6988 and turns ISOweek, classInt and countrycode back to Imports. The other option is to make these packages optional in documentation and tests like the sf and giscoR packages are optional now.

Done. If it seems too complicated I can just revert the whole thing to what it was.

For some reason when I rebuild docs on my computer (R version 4.6.1) the printed version of the citation has a dot between "https://doi.org/10.32614/CRAN.package.eurostat" and "R package version" whereas documentation built on your computer has a comma between those. Weird.

I re-ran the tests on win-release and win-devel and removed Gitter links from the README.md file for the CRAN release. I think we can re-add them after submitting, although Gitter is not used that much (at all).

Maybe we can just remove Gitter? Should we activate the Github "Discussions" tab? That provides a forum in case someone needs. The link could be updated accordingly.

Weird thing with period vs. comma.. what shall we do with that..?

I don't know if GitHub discussions has a separate button we could include but I can add a link to Discussions.

ChatGPT suggested that it might be related to R version and R package versions related to printing the output (so R version since we use the bibentry function from built-in utils package) or more likely system locale. Mine is

> Sys.getlocale()
[1] "en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8"

so it's not a big deal but just annoying since the citation is included in so many help files (because it makes software citations more likely than just burying it in eurostat-package).

Now good? This was R build version issue.

Everything seems to be in order now. I think it's ready for release.

Only thing I wonder if whether we should squash all the commits in this PR into one 4.1.0 release since these versions after 4.1.1 have been very minor improvements that, in my opinion, don't even deserve to be documented in NEWS.md. But going forward with 4.1.4 as the CRAN release version is fine by me as well, maybe we could add a new NEWS section for 4.1.4 that pulls everything together.