-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
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 |
I plan to fix isoband. Am currently traveling but will probably get to it this week nonetheless. |
@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 |
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 |
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. |
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 |
@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. |
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 |
Very sorry about all this hassle @clauswilke 😞, weirdly testthat got a deadline of Oct 19, so the testthat release is planned for Oct 7. |
@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. |
@clauswilke let me test it for you, a minute. |
@gaborcsardi Super, thanks! |
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. |
@clauswilke OK, confirmed. CRAN version fails, your current GH HEAD succeeds. |
Updated isoband is on CRAN, clang issues have been resolved. |
An email from Prof. Brian Ripley to CRAN maintainers states
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 onisobands
to have this issue at least solved for all the downstream dependencies?The text was updated successfully, but these errors were encountered: