[R-pkg-devel] Question about preventing CRAN package archival
Ben Staton
@t@tonbe @end|ng |rom gm@||@com
Thu Jun 3 19:35:07 CEST 2021
Hi Everyone,
Thank you all for your input and thoughts on this topic. I've learned much
from this thread. I have arrived at a solution so we can now consider this
topic closed.
I ended up removing the dependency on 'matrixcalc' by (a) replacing
matrixcalc::is.square.matrix() with a basic check for nrow(x) == ncol(x),
(b) replacing matrixcalc::is.symmetric.matrix() with base::isSymmetric(),
and (c) replacing matrixcalc::is.positive.definite() with some basic custom
code that checks eigenvalues for >= 0 (thus checking for semi-positive
definiteness), as pointed out by Martin above. I have submitted the updated
version to CRAN and it is now available there.
Side note -- someone else ended up taking over as maintainer of the
orphaned 'matrixcalc' package and has had it successfully accepted to CRAN,
so it will continue to be available going forward. I'm still happy with the
solution that I used, as fewer dependencies the better -- a point also
raised earlier in this thread.
Thank you all,
Ben
On Thu, Jun 3, 2021 at 12:55 AM Martin Maechler <maechler using stat.math.ethz.ch>
wrote:
> >>>>> Avraham Adler
> >>>>> on Wed, 2 Jun 2021 15:28:25 -0400 writes:
>
> > Exactly. Is square is just brow=ncol, is positive definite can be
> > implemented as a check that all eigenvalues > 0, which can be done
> with
> > base, and is.symmetric can be simply brute forced in a loop
> comparing i,j
> > with j,i.
>
> > The fewer dependencies a package has, the more robust it is. It’s a
> fine
> > balance between not reinventing the wheel and ceding too much
> stability to
> > other packages.
>
> > Thanks,
> > Avi
>
> Indeed. Further,
>
> - isSymmetric() has been part of base for a long time
> so the definition of an alternative in matrixcalc had been @_*#^$%
> It's also supported by methods in the Matrix package
> e.g. for sparse matrices etc so definitely something you
> "should" use instead.
>
> - is.square() is trivial and I think an explicit check such as
> { d <- dim(x); d[1] == d[2] }
> is often more sensical, notably as in many of your functions
> you'd need either nrow(.) or ncol(.) of your matrix anyway.
>
> - A remark on Positive Definiteness (or also, often what you really want,
> "Positive Semi-definitness", allowing 0 eigen values):
> The Matrix package has an (S4) class "dpoMatrix"
> of dense positive-definite (actually 'positive semi-definite') matrices.
> In its validation method (yes, formal classes have validation!), we
> use a cheap test instead of an expensive test with eigenvalues
> (which is "too expensive": there are faster ones at least in theory,
> e.g., trying an LDL' Cholesky decomposition and returning as soon as
> a non-positive / negative entry in D would appear).
>
> The really cheap "pre-test" you may want to use before or instead
> of doing one of the more expensive ones is simply checking the diagonal:
>
> if(any(diag(<matrix>)) < 0) "not positive-semidefinite"
> if(any(diag(<matrix>)) <= 0) "not positive-definite"
>
> Martin Maechler
> (Maintainer of 'Matrix').
>
>
> > On Wed, Jun 2, 2021 at 3:15 PM John Harrold <
> john.m.harrold using gmail.com>
> > wrote:
>
> >> To add another option. In the past when this has happened to me
> I've found
> >> other packages that provide similar functionality.
> >>
> >> I'm assuming that is.square just checks the number of columns ==
> number of
> >> rows? And the others can probably be implemented pretty easily.
> >>
> >> On Wed, Jun 2, 2021 at 10:41 AM Ben Staton <statonbe using gmail.com>
> wrote:
> >>
> >> > My package uses the MIT license, so would that not meet the
> compatibility
> >> > requirements?
> >> >
> >> > I will attempt to reach out to the package author - thanks for
> your help!
> >> >
> >> > On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker <bbolker using gmail.com>
> wrote:
> >> >
> >> > > That all sounds exactly right.
> >> > > GPL >= 2 allows you to use the material without asking
> permission as
> >> > > long as your package is compatibly licensed (e.g. also GPL).
> >> > > Under normal circumstances it would be polite to ask
> permission, but
> >> > > if the reason for doing this is that the maintainer is
> unreachable in
> >> > > the first place ...
> >> > >
> >> > > If you want to try a little harder, it seems quite possible
> that you
> >> > > can reach the matrixcalc maintainer at the (personal) e-mail
> address
> >> > > shown in this page:
> >> > >
> >> > >
> >> >
> >>
> https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042
> >> > >
> >> > > (Possibly an identity confusion, but I rate that as unlikely
> based
> >> on
> >> > > other facebook snooping)
> >> > >
> >> > > I don't think a short, polite e-mail request would be out of
> bounds,
> >> > > they can always ignore it or tell you to go away.
> >> > >
> >> > > cheers
> >> > > Ben Bolker
> >> > >
> >> > > On 6/2/21 1:15 PM, Ben Staton wrote:
> >> > > > Hello,
> >> > > >
> >> > > > Thank you for your detailed list of solutions.
> >> > > >
> >> > > > I was initially tempted to go with option 1 (move matrixcalc
> to
> >> > suggests
> >> > > > and check for its existence before using functions that rely
> on it),
> >> > but
> >> > > as
> >> > > > mentioned, this is not a long term fix.
> >> > > >
> >> > > > I unfortunately can't take on the responsibilities of option 2
> >> > (becoming
> >> > > > the package maintainer) -- there is much that this package
> does that
> >> I
> >> > do
> >> > > > not understand, and do not wish to feign authority!
> >> > > >
> >> > > > I plan to take option 3 (copy the needed functions into my
> package).
> >> > > There
> >> > > > are only three functions I need from matrixcalc, and all
> three are
> >> > fairly
> >> > > > simple (is.square.matrix
> >> > > > <https://rdrr.io/cran/matrixcalc/src/R/is.square.matrix.R>,
> >> > > > is.symmetric.matrix
> >> > > > <https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>,
> and
> >> > > > is.positive.definite
> >> > > > <https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>)
> and
> >> > > there
> >> > > > is only one function in postpack that needs them. I plan to
> define
> >> them
> >> > > > within the postpack function. matrixcalc is licensed under
> GPL >= 2
> >> and
> >> > > > based on my scan of the license text, this is allowed. Is that
> >> correct?
> >> > > >
> >> > > > Regarding option 4 (contacting the matrixcalc maintainer), the
> >> original
> >> > > > email from CRAN mentioned that they have attempted to contact
> the
> >> > package
> >> > > > author with no response.
> >> > > >
> >> > > > Thank you!
> >> > > >
> >> > > > On Wed, Jun 2, 2021 at 9:52 AM J C Nash <profjcnash using gmail.com
> >
> >> wrote:
> >> > > >
> >> > > >> 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 using r-project.org mailing list
> >> > > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> > > >>
> >> > > >
> >> > > > [[alternative HTML version deleted]]
> >> > > >
> >> > > > ______________________________________________
> >> > > > R-package-devel using r-project.org mailing list
> >> > > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> > > >
> >> > >
> >> > > ______________________________________________
> >> > > R-package-devel using r-project.org mailing list
> >> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> > >
> >> >
> >> > [[alternative HTML version deleted]]
> >> >
> >> > ______________________________________________
> >> > R-package-devel using r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >> >
> >>
> >>
> >> --
> >> John
> >> :wq
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-package-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> > --
> > Sent from Gmail Mobile
>
> > [[alternative HTML version deleted]]
>
> > ______________________________________________
> > R-package-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
More information about the R-package-devel
mailing list