I just downloaded the source matrixcalc package to see what it contained. The functions I looked at seem fairly straightforward and the OP could likely develop equivalent features in his own code, possibly avoiding a function call. Avoiding the function call means NAMESPACE etc. are not involved, so fewer places for getting into trouble, assuming the inline code works properly.
JN On 2021-06-02 12:37 p.m., Duncan Murdoch wrote: > On 02/06/2021 12:13 p.m., Ben Staton wrote: >> Hello, >> >> I received an email notice from CRAN indicating that my R package >> ('postpack') will be archived soon if I do not take any action and I want >> to avoid that outcome. The issue is not caused by my package, but instead a >> package that my package depends on: >> >> "... package 'matrixcalc' is now scheduled for archival on 2021-06-09, >> and archiving this will necessitate also archiving its strong reverse >> dependencies." >> >> Evidently, xyz has been returning errors on new R builds prompting CRAN to >> list it as a package to be archived. My package, 'postpack' has >> 'matrixcalc' listed in the Imports field, which I assume is why I received >> this email. >> >> I want to keep 'postpack' active and don't want it to be archived. I still >> need package 'matrixcalc' for my package, but not for most functions. Could >> I simply move package 'matrixcalc' to the Suggests list and submit the new >> version to CRAN to remove the "Strong Reverse Dependency" issue that >> triggered this email to avoid CRAN from archiving my package? > > That's part of one solution, but not the best solution. > > If you move it to Suggests, you should make sure that your package checks for > it before every use, and falls back to > some other calculation if it is not present. Be aware that once it is > archived, almost none of your users will have it > available, so this is kind of like dropping the functions that it supports. > > Another solution which would be great for the community might be for you to > offer to take over as maintainer of > matrixcalc. Then you'd fix whatever problems it has, and you wouldn't need > to worry about it. I haven't looked at the > issues so I don't know if this is feasible. > > A third choice would be for you to copy the functions you need from > matrixcalc into your own package so you can drop the > dependency. This is generally legal under the licenses that CRAN accepts, > but you should check anyway. > > A fourth choice would be for you to contact the matrixcalc maintainer, and > help them to fix the issues so that > matrixcalc doesn't get archived. They may or may not be willing to work with > you. > > I'd say my third choice is the best choice in the short term, and 2nd or 4th > would be good long term solutions. > > Duncan Murdoch > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel