gt has changed the default table position from !t to t

[yihui]

cf rstudio/gt#1935

Due to our use of skip_on_cran() in tests/testthat/test-independent_as_gt.R, the gt maintainer failed to detect this breakage in our package before the new CRAN release of gt. I'd strongly recommend that we reserve the use of skip_on_cran() only for the absolute necessary cases (e.g., complicated dependencies that CRAN may not have). The skip was from the PR #371 by @nanxstats but I don't quite understand the rationale. If changes in gt break our tests, gt should be responsible for the problem, not us. In fact, gt won't be able to make the new release to CRAN before fixing the problem with us, so we shouldn't have any problem with the existing CRAN release of our package.

[LittleBeannie]

Thanks, @yihui!

[nanxstats]

@yihui I think we can agree on the problem (upstream dependencies make breaking changes that will break downstream packages tests easily), but I respectfully disagree with the recommendation on not using skip_on_cran().

The rationale has been explained in #371, but maybe it can use more clarity: having to make frequent CRAN updates due to upstream dependency changes adds unnecessary time and efforts burden to maintainers (see previous examples: Merck/simtrial#234, keaven/gsDesign#115). Although we welcome gt authors to send PRs to fix the problems, it is us who still have to make CRAN releases, and you know that is not as trivial as releasing a Python package to PyPI due to the high standards. We also don't want to be a potential blocker for gt's CRAN releases.

[yihui]

@nanxstats Thanks for the explanation! I understand it better now. However, I think it's actually a great thing for us to be a potential blocker for the CRAN releases of packages that we depend on (sometimes someone has to be "that guy" :). That's the whole point of CRAN requiring revdep checks---upstream packages can't easily make arbitrary changes without letting downstream packages know. I guess we have no disagreement on this.

The only thing to discuss is the potential trouble for us to have to make a new CRAN release before upstream packages bring their breaking changes to CRAN. I wouldn't worry too much about it for two reasons:

1. The most difficult task in making a new CRAN release is the revdep checks. gsDesign2 only has one reverse dependency (our own simtrial). This task sounds straightforward. I bet we can easily pass CRAN's automated checks in minutes after submission.

2. If upstream packages make breaking changes too frequently, their maintainers should have a way to notice it and reconsider their decisions. If we give up our downstream privilege, we can only passively accept upstream changes. In this particular case (!t to t), I don't think it matters much, but if gt makes another change that matters to us, we will have to either make a new CRAN release to work around their change, or ask them to revert the change and make a new release. That sounds like even bigger trouble to me.

I think the potential burden you mentioned would be worthwhile, as it offers us better guarantee on whether our package does what we expect it to at any time. If we passively wait for upstream changes, there might be a (short) time period in which our package "works" on CRAN but breaks in practice. I may well be paranoid here, but just want to point out the possibility and cost. I don't really have a strong opinion on this, so it's totally fine to leave it behind.

[nanxstats]

@yihui I actually agree with everything you said.

I guess our optimization objective has been inexplicitly set to minimize maintainer time and effrot investment, instead of "doing the right thing" and "be that guy". In our reality, people have other business priorities and can't do this full time.

Previously, I suggested the team to adopt a practice of making more regular CRAN releases unconditionally (like once a month or so) but failed for similar reasons. So to me, this is more of a social issue instead of a technical issue.

[yihui]

Totally understood!