Upkeep

[olivroy]

As a follow-up, would you be open to the following upkeep actions?

I could do a PR fo each of these before you finalize the v4 interface.

• add dontrun to failing examples for now to pass CI (CI progress #779)
• Use a very simple testthat setup to help detect errors (i.e this would just help to ensure things do not break. (CI progress #779)

this would be very helpful to be able to see what passes and fails depending on the OS, package version.

I know tmap is probably difficult to manage and submit to cran.
We can use skip_on_ci(), skip_on_cran(), skip_on_os("windows"), skip_on_os("linux") in the appropriate places.

I think these would smoothen transition from v3 to v4.

• Move the build/ folder to data-raw and remove rgdal. i.e. build them with sf? I don't know caveats for that or consideration for backward compatibility of older spatial objects. (Spell check + move build to data-raw #782)

After that, in my opinion, it may be easier to address outstanding issues more efficiently by knowing exactly what's failing and without the fear to break something silently.

• Creating failing tests of the required behavior is a good way to have a todo list!
• Add any documentation you think is useful, but difficult to manage on Cran as an article.

Again, feel free to close if you don't think you have the time to manage this.

I also suggest you create a new repo for tmap3 to host the documentation website there before release maybe and point people to the v4 replacement.

Edit: overall in #775, #779, #780, #782, #783, #784, #785, #786, #787 I did a round of upkeep to update the website, the documentation, internals, handling of suggested packages, to make future development a little bit easier.

[mtennekes]

Thanks @olivroy ! Those 5 tasks sound good to me, but maybe I oversee things (@Nowosad @Robinlovelace )

Shall we create a new repo for tamp3, @Nowosad ? Or stick to the branch 'v3'? It makes sense to host the documentation of both versions simultaneously, at least for some period of time (transition period).

I thought and tried a testthat setup, but somewhere dropped the ball, because it is more of a struggle to compare graphics. However, it can be done. So if you have the time @olivroy , please feel free to go ahead.

[Nowosad]

My few comments:

1. "add dontrun to failing examples for now to pass CI": @mtennekes -- maybe if there are one or two failing examples, an easier way would be just to fix them?
2. "Use a very simple testthat setup": it would be good to have a testthat setup; however given the tmap size and scope, I do not know how complete this setup should be. Also, I would suggest using skip_on_ci(), skip_on_cran(), skip_on_windows() as much as possible to minimize the possible submission issues/time wasted.
3. "Move the build/ folder to data-raw and remove rgdal. i.e. build them with sf?" 👍🏻
4. Regarding two websites: I just made a tmap 3 release at https://github.com/r-tmap/tmap/releases. Is it enough to create a sub-website?

[olivroy]

Thanks for your replies @mtennekes and @Nowosad.

1. "add dontrun to failing examples for now to pass CI": @mtennekes -- maybe if there are one or two failing examples, an easier way would be just to fix them?

In #779, I realized there was only one failing example. But it would require the implementation of tm_main_title(). By skipping it, I am able to pass CI, except for some failing tests.

2. "Use a very simple testthat setup": it would be good to have a testthat setup; however given the tmap size and scope, I do not know how complete this setup should be. Also, I would suggest using skip_on_ci(), skip_on_cran(), skip_on_windows() as much as possible to minimize the possible submission issues/time wasted.

I tried that a little. But it seems a bit long to do. Local tests were more developed than I saw initially

4. Regarding two websites: I just made a tmap 3 release at https://github.com/r-tmap/tmap/releases. Is it enough to create a sub-website?

I don't really know. The pkgdown workflow was not working at v 3.3-4. Here is the reference for this, but I have never done it. https://pkgdown.r-lib.org/articles/how-to-update-released-site.html

Thanks for doing the GH release, it should help!

And about the raw namespace piece for knitr, there may be some guidance to remove that? yihui/knitr#1929 but can you let me know why it was used?

Also, is R 3.6 still supported. (tmaptools requires XML which requires R 4.0 anyways), so maybe it could just be removed.

[olivroy]

@mtennekes I know how to make the pkgdown site show both released + dev version of tmap. I would need to have write access to trigger the workflow.. https://pkgdown.r-lib.org/dev/articles/how-to-update-released-site.html

[mtennekes]

I've invited you @olivroy to be co-owner of the whole r-tmap gh group. Should be sufficient (if not, let me know). Thx!

[olivroy]

Got it!
3.3-4 https://r-tmap.github.io/tmap/
3.99.9001 https://r-tmap.github.io/tmap/dev/