Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can dependency of isoband be avoided somehow due to impending CRAN archival #5006

Closed
kapsner opened this issue Oct 5, 2022 · 15 comments
Closed

Comments

@kapsner
Copy link

kapsner commented Oct 5, 2022

An email from Prof. Brian Ripley to CRAN maintainers states

CRAN package isoband and its reverse dependencies
...
We have asked for an update fixing the check problems shown at
https://cran.r-project.org/web/checks/check_results_isoband.html
with no update from the maintainer thus far.
Thus, package isoband is now scheduled for archival on 2022-10-19, and
archiving this will necessitate also archiving its CRAN strong reverse
dependencies.

This concerns hundreds of R packages.

Most probably this is related to the fact that a vast majority of these packages import ggplot2.

Would it somehow be possible that ggplot2 avoids to rely on isobands to have this issue at least solved for all the downstream dependencies?

@thomasp85
Copy link
Member

Yes, I got that mail as well. I've reached out to CRAN and we will find a solution - thousands of packages are not suddenly going to get archived due to this

@clauswilke
Copy link
Member

I plan to fix isoband. Am currently traveling but will probably get to it this week nonetheless.

@thomasp85
Copy link
Member

@clauswilke do you know if this concerns anything else but the unused variable warning? Also, if you need help to fix and submit let me know

@clauswilke
Copy link
Member

clauswilke commented Oct 5, 2022

It's this issue: r-lib/isoband#31

A fix has been applied for testthat, I just need to copy it over. I was just waiting a bit to see if any problems did arise for testhat, and it's good I did because the first fix had a problem and needed some additional corrections: r-lib/testthat#1694

@clauswilke
Copy link
Member

I also would like to say that the way CRAN approaches these issues, by sending threatening emails and otherwise not engaging at all with developers, is highly dysfunctional. I opened an issue (r-lib/isoband#31) the day I received notification that there was a problem, I informed @hadley right away, and I checked in with the progress of the fix for the testthat package. Right now I'm traveling, but also since my fix is basically copying code over from testthat, I was waiting for testthat to hit CRAN first. I think that's totally reasonable behavior, and I'll note that the CRAN maintainers know that my problem stems from code copied from testthat. They mentioned this in their email to me. But they never sent a follow-up check-in email or check in on github in the issue I opened. They simply now send out mass emails stating that the entire ecosystem will fall apart in mid-October.

All in all, these kinds of situations make me not want to maintain critical infrastructure in the R ecosystem. @thomasp85 and @hadley, if RStudio wants to formally take over maintainership of isoband I'm happy to hand over the reigns. There isn't really much to be done in terms of maintaining anyways. The last few years the only fixes needed were related to breakages in the code copied over from testthat.

@thomasp85
Copy link
Member

Yes, I agree this response from CRAN is quite sad and I understand why you feel as you do. I'm happy to take on maintenance partly or fully if that is what you wish, though I'm sad about the circumstances for it

@clauswilke
Copy link
Member

@thomasp85 In the particular case of isoband I actually have been thinking about this for a long time, because it's critical infrastructure for ggplot2 and sooner or later something like this was going to happen. I think having a company be formally in charge of the code is the right thing to do, and we can talk about what's the best way to do this. I'll handle the current release and then afterwards we can talk about the appropriate maintainership structure.

@thomasp85
Copy link
Member

Sounds good - again, let me know if there is anything I can do to help with the current issue. Right now I'm just putting fires out on twitter

@hadley
Copy link
Member

hadley commented Oct 5, 2022

Very sorry about all this hassle @clauswilke 😞, weirdly testthat got a deadline of Oct 19, so the testthat release is planned for Oct 7.

@clauswilke
Copy link
Member

@hadley No worries. I just copied over the testthat headers. Tests are all passing on my end. If somebody with the latest llvm could test the isoband development version that would be great, otherwise I'll just submit and hope for the best.

@gaborcsardi
Copy link
Member

@clauswilke let me test it for you, a minute.

@clauswilke
Copy link
Member

@gaborcsardi Super, thanks!

@gaborcsardi
Copy link
Member

Actually, it is not about the compiler, but the C++ library. The compiler is fine with the CRAN version, too. Let me try a bit more.

@gaborcsardi
Copy link
Member

@clauswilke OK, confirmed. CRAN version fails, your current GH HEAD succeeds.

@clauswilke
Copy link
Member

Updated isoband is on CRAN, clang issues have been resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants