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
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
