Potential cache delay on CRANberries(?)

[HenrikBengtsson]

Today's archived 'docxtools' package is picked up by our dashboard, but not by update.R, which queries CRANberries, running on GitHub Acgtions. Running 'update.R' from my local computer picks up 'docxtools'. So, it looks there's some web caching going on.

[llrs]

I don't know how is the CRAN process, but I think that as much as we can we should rely on them for this information (even if in occasions it might be wrong).

This would also provide a pathway to collaborate with the CRAN team. We are using a somewhat exposed functionality used to manage the repository. If they are open (or we search deeper in the svn R-dev-web repo) we could learn how they do this and maybe contribute with some tools/advice.

[HenrikBengtsson]

Agree - all great ideas.

Regarding data sources: I suspect the most reliable source is tracking the PACKAGES file over time, which btw I think is how CRANberries does it. Alternatively, tools:::CRAN_current_db() and tools:::CRAN_archive_db() are equally reliable. As I mentioned elsewhere, PACKAGES.in may have typos (e.g. wrong date in the comment field), so it should probably not be the main source, or at least it's too early to say we can trust it 100%.

BTW, this staring to smell more and more like it's worth creating a cranhaven package to encapsulate all this. That package don't need to be on CRAN (probably shouldn't).

[llrs]

I have been thinking about creating a package to manage the output o tools:::CRAN_current_db() and tools:::CRAN_archive_db()for a while.
I have several lines of code that might fit in this package.

The r-release project also went with creating a package (in this case for the end user). But here it might be equally to help with the creation and maintenance of the cranhaven.r-universe.org and for users.

[HenrikBengtsson]

Excellent. Feel free to start a new pkg repo for this.