[R-pkg-devel] Question about preventing CRAN package archival

Martin Maechler m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Thu Jun 3 09:55:12 CEST 2021


>>>>> 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



More information about the R-package-devel mailing list