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

[Ben Bolker]

  Write to the CRAN maintainers and let them know about the situation, 
hopefully that would prevent archiving.


On 6/2/21 4:16 PM, Ben Staton wrote:

Hi Everyone, thank you all for your responses.

I agree that I can replicate the three functions within matrixcalc that I
need with ease, even without copying and pasting the original code found in
that package and thus not creating any licensing issues.

I have checked the CRAN incoming boards (here
), and they
actually have a new version of matrixcalc coming through so hopefully this
issue will be resolved without my intervention.

On a related note, suppose that this issue does not get resolved before the
archival date, and my package gets archived. What would be the path for me
to have CRAN remove it from the archived list? Is it basically (1) fix the
issue that caused initial archival and (2) resubmit?

Thank you,
Ben

On Wed, Jun 2, 2021 at 12:48 PM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:


   The CRAN maintainers almost certainly have tried to contact the
maintainer.  You can ask if he plans to fix the bug.  If not, if it's
that easy to fix, you could offer to both the maintainers of both
matrixcalc and CRAN to take over maintenance.


   Spencer


On 6/2/21 2:41 PM, Roy Mendelssohn - NOAA Federal via R-package-devel
wrote:

After looking up matrixcalc on CRAN,  I would recommend contacting the

maintainer,  who is listed as:



Frederick Novomestky 



The reason I say this is what is blowing up the package in the nightly

builds is a careless error in one Example:



> x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4,

ncol=4, byrow=TRUE )

  Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4,

ncol = 4, :

   data length differs from size of matrix: [12 != 4 x 4]



That should be pretty easy for the maintainer to fix and to resubmit.

-Roy



On Jun 2, 2021, at 10:36 AM, Ben Staton  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  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=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
,
is.symmetric.matrix
, and
is.positive.definite
) 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  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 

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

[Ben Staton]

Hi Everyone, thank you all for your responses.

I agree that I can replicate the three functions within matrixcalc that I
need with ease, even without copying and pasting the original code found in
that package and thus not creating any licensing issues.

I have checked the CRAN incoming boards (here
), and they
actually have a new version of matrixcalc coming through so hopefully this
issue will be resolved without my intervention.

On a related note, suppose that this issue does not get resolved before the
archival date, and my package gets archived. What would be the path for me
to have CRAN remove it from the archived list? Is it basically (1) fix the
issue that caused initial archival and (2) resubmit?

Thank you,
Ben

On Wed, Jun 2, 2021 at 12:48 PM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

>   The CRAN maintainers almost certainly have tried to contact the
> maintainer.  You can ask if he plans to fix the bug.  If not, if it's
> that easy to fix, you could offer to both the maintainers of both
> matrixcalc and CRAN to take over maintenance.
>
>
>   Spencer
>
>
> On 6/2/21 2:41 PM, Roy Mendelssohn - NOAA Federal via R-package-devel
> wrote:
> > After looking up matrixcalc on CRAN,  I would recommend contacting the
> maintainer,  who is listed as:
> >
> >> Frederick Novomestky 
> >
> >
> > The reason I say this is what is blowing up the package in the nightly
> builds is a careless error in one Example:
> >
> >>> x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4,
> ncol=4, byrow=TRUE )
> >>  Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4,
> ncol = 4, :
> >>   data length differs from size of matrix: [12 != 4 x 4]
> >>
> >
> > That should be pretty easy for the maintainer to fix and to resubmit.
> >
> > -Roy
> >
> >
> >> On Jun 2, 2021, at 10:36 AM, Ben Staton  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  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=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
>  ,
>  is.symmetric.matrix
>  , and
>  is.positive.definite
>  ) 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  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, 

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

[Spencer Graves]

	  The CRAN maintainers almost certainly have tried to contact the 
maintainer.  You can ask if he plans to fix the bug.  If not, if it's 
that easy to fix, you could offer to both the maintainers of both 
matrixcalc and CRAN to take over maintenance.



  Spencer


On 6/2/21 2:41 PM, Roy Mendelssohn - NOAA Federal via R-package-devel wrote:

After looking up matrixcalc on CRAN,  I would recommend contacting the 
maintainer,  who is listed as:


Frederick Novomestky 



The reason I say this is what is blowing up the package in the nightly builds 
is a careless error in one Example:


   > x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4, ncol=4, 
byrow=TRUE )
 Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4, ncol = 4, 
:
  data length differs from size of matrix: [12 != 4 x 4]



That should be pretty easy for the maintainer to fix and to resubmit.

-Roy



On Jun 2, 2021, at 10:36 AM, Ben Staton  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  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=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
,
is.symmetric.matrix
, and
is.positive.definite
) 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  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 

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

[Roy Mendelssohn - NOAA Federal via R-package-devel]

After looking up matrixcalc on CRAN,  I would recommend contacting the 
maintainer,  who is listed as:

> Frederick Novomestky 


The reason I say this is what is blowing up the package in the nightly builds 
is a careless error in one Example:

>   > x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4, ncol=4, 
> byrow=TRUE )
> Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4, ncol = 
> 4, : 
>  data length differs from size of matrix: [12 != 4 x 4]
> 

That should be pretty easy for the maintainer to fix and to resubmit.

-Roy


> On Jun 2, 2021, at 10:36 AM, Ben Staton  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  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=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
>>> ,
>>> is.symmetric.matrix
>>> , and
>>> is.positive.definite
>>> ) 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  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, 

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

[Avraham Adler]

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

On Wed, Jun 2, 2021 at 3:15 PM John Harrold 
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  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  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=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
> > > > ,
> > > > is.symmetric.matrix
> > > > , and
> > > > is.positive.definite
> > > > ) 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 
> 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
> > 

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

[J C Nash]

As noted by John Harrold and my previous posting, these are not monster codes.
I'd check what I needed and simply work out enough R to make my package work.
Most of these matrix functions are pretty much old-fashioned math translated
into R. I can't see that R will engage lawyers if the OP translates the variable
names to the ones he is using and more or less mimics the bits of code needed.

Cheers, JN


On 2021-06-02 3:15 p.m., John Harrold 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  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  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=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
 ,
 is.symmetric.matrix
 , and
 is.positive.definite
 ) 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  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
>> 

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

[John Harrold]

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  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  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=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
> > > ,
> > > is.symmetric.matrix
> > > , and
> > > is.positive.definite
> > > ) 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  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
> > 

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

[Jeff Newmiller]

MIT is more permissive than GPL2, so there is a collision there. But you may be 
able to work it out with the author?

On June 2, 2021 10:36:00 AM PDT, Ben Staton  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  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=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
>> > ,
>> > is.symmetric.matrix
>> > , and
>> > is.positive.definite
>> > ) 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 
>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 

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

[Ben Staton]

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  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=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
> > ,
> > is.symmetric.matrix
> > , and
> > is.positive.definite
> > ) 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  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 

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

[Ben Bolker]

   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=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
,
is.symmetric.matrix
, and
is.positive.definite
) 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  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@r-project.org mailing list

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

[Ben Staton]

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
,
is.symmetric.matrix
, and
is.positive.definite
) 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  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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[J C Nash]

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

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

[Duncan Murdoch]

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-pkg-devel] Question about preventing CRAN package archival

[Ben Staton]

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?

Thanks in advance for any advice you can provide!

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Krzysztof Bartoszek]

Looking manually the chain is actually different
mvSLOUCH <--- TreeSim <-- geiger <-- phytools <-- gtools
TreeSim does not import anything directly from phytools

But given the amount of packages that depend on gtools and seeing how long the 
above path is, I wonder how many packages on CRAN are experiencing some sort of 
issues.
Best wishes
Krzysztof Bartoszek


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, June 2, 2021 11:10 AM, Hugh Parsonage  
wrote:

> First I confirmed "gtools" %in% tools::package_dependencies("mvSLOUCH")[[1]]
>
> then
>
> lapply(tools::package_dependencies("mvSLOUCH"),
> tools::package_dependencies, recursive = TRUE)
>
> was sufficient to identify the chain.
>
> On Wed, 2 Jun 2021 at 21:08, Duncan Murdoch murdoch.dun...@gmail.com wrote:
>
> > On 02/06/2021 6:57 a.m., Hugh Parsonage wrote:
> >
> > > mvSLOUCH <--- TreeSim <-- phytools <-- gtools
> > > On Wed, 2 Jun 2021 at 20:35, Krzysztof Bartoszek krz...@protonmail.ch 
> > > wrote:
> > >
> > > > Thank you. The only problem, as I wrote, is that neither my package, 
> > > > mvSLOUCH, nor any package that mvSLOUCH imports from depends on gtools.
> > > > In particular nowhere in mvSLOUCH do I use any call to anything from 
> > > > gtools nor to any function called combinations.
> >
> > Hugh, could you describe how you found this dependency chain? This sort
> > of problem comes up now and then, and I've always used a slow manual
> > search. It would be nice to know if there's an automatic way to answer
> > the question
> > "Why does package xxx appear to require yyy?"
> > Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] \donttest{} and writing outputs to tempdir()

[Spencer Graves]

	  You surely should be able to have some examples that would run in 
less than 5 seconds.



	  I almost never use "donttest".  Instead I use conditional skips, and 
those only on examples that I believe are likely to run too long.  In 
those cases, I believe the standard recommendation is:



testthat::skip_on_cran


https://testthat.r-lib.org/reference/skip.html


HOWEVER:  To use this, users must manually set Sys.getenv("NOT_CRAN") to 
"true" if they want the tests to run in environments that are not CRAN. 
 I don't perceive the documentation on this to be adequate;  I'd rather 
not have to set an environment variable in every new environment that 
I'd like to have run all the tests.  Therefore, some years ago, I added 
a CRAN function to the fda package, which I use as follows:



if(!fda::CRAN()){

# code I don't want to run on CRAN
# but do want to run elsewhere.
# You can use:
# R CMD check --as-cran
# to see if it works OK on CRAN


}


  Spencer


On 6/2/21 12:29 AM, Jeff Newmiller wrote:

Make examples shorter so they can run faster. Wrapping everything in donttest 
means that running examples() does nothing, which is counterproductive.

Techinically, vignettes are not tests or examples... but they do have the 
advantage that they don't have to run quickly. But that doesn't make a vignette 
a substitute for either examples or tests.

As for writing to the wrong place, you should probably just double check.

On June 1, 2021 9:39:43 PM PDT, Danielle Maeser  wrote:

Hello,

I received the following comments from a CRAN maintainer, and I don't
understand why they were an issue. I'd appreciate any insight you can
provide.

Danielle







*All your examples are wrapped in \donttest{} and therefore do not
gettested.Please unwrap the examples if that is feasible and if they
can
beexecuted in < 5 sec for each Rd file or create additionally small
toyexamples to allow automatic testing.*

I don't think I can unwrap the examples in \donttest{} because they
cannot
be executed in <5 seconds for each Rd file, and the automatic testing
of
toy data is satisfied in the vignettes I provide for each function.
Therefore, I am not sure what change to make here.




*Please ensure that your functions do not write by default or in
yourexamples/vignettes/tests in the user's home filespace (including
thepackage directory and getwd()). This is not allowed by CRAN
policies.In
your examples/vignettes/tests you can write to tempdir().*

Additionally, all of my vignettes write the output of each function to
tempdir(). Therefore, I am not sure why this is a problem.




__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] problem with submitting to CRAN (windows)

[Krzysztof Bartoszek]

Thank you. The only problem, as I wrote, is that neither my package, mvSLOUCH, 
nor any package that mvSLOUCH imports from depends on gtools.
In particular nowhere in mvSLOUCH do I use any call to anything from gtools nor 
to any function called combinations.

Best wishes
Krzysztof Bartoszek


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, June 2, 2021 10:25 AM, Hugh Parsonage  
wrote:

> Probably a consequence of gtools having build errors
> (https://cran.r-project.org/web/checks/check_results_gtools.html)
>
> I'd recommend reconsidering use of the package until the problems are
> resolved. In the meantime, put gtools is Suggests for the use of
> combinations(). Note the base R functions choose and combn that might
> be sufficient (and certainly more available).
>
> On Wed, 2 Jun 2021 at 20:17, Krzysztof Bartoszek krz...@protonmail.ch wrote:
>
> > Dear all,
> > I am trying to submit an update of my mvSLOUCH package to CRAN an am 
> > getting the following problem from the automatic pretest:
> > Dear maintainer,
> > package mvSLOUCH_2.6.5.tar.gz does not pass (yesterday and today) the 
> > incoming checks automatically, please see the following pre-tests:
> > Windows: 
> > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00check.log
> > Status: 1 ERROR
> > Debian: 
> > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Debian/00check.log
> > Status: OK
> > The windows error in 
> > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00install.out
> > is
> > ** byte-compile and prepare package for lazy loading
> > Error: object 'combinations' is not exported by 'namespace:gtools'
> > Execution halted
> > ERROR: lazy loading failed for package 'mvSLOUCH'
> > Interestingly when I today submited to winbuilder (devel) no such issues 
> > are raised (yesterday the same issue was raised by winbuilder-devel):
> > https://win-builder.r-project.org/Ou1tDLkY8HVB/
> > It feels a bit strange that this package dependency fails only for Windows, 
> > especially as neither mvSLOUCH nor any of the packages it imports from 
> > depend on gtools.
> > I would be very grateful for assistance.
> > Best wishes
> > Krzysztof Bartoszek
> > Sent with ProtonMail Secure Email.
> > [[alternative HTML version deleted]]
> >
> > 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

[R-pkg-devel] problem with submitting to CRAN (windows)

[Krzysztof Bartoszek]

Dear all,
I am trying to submit an update of my mvSLOUCH package to CRAN an am getting 
the following problem from the automatic pretest:
Dear maintainer,

package mvSLOUCH_2.6.5.tar.gz does not pass (yesterday and today) the incoming 
checks automatically, please see the following pre-tests:
Windows: 

Status: 1 ERROR
Debian: 

Status: OK

The windows error in 
https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00install.out
is
** byte-compile and prepare package for lazy loading
Error: object 'combinations' is not exported by 'namespace:gtools'
Execution halted
ERROR: lazy loading failed for package 'mvSLOUCH'

Interestingly when I today submited to winbuilder (devel) no such issues are 
raised (yesterday the same issue was raised by winbuilder-devel):
https://win-builder.r-project.org/Ou1tDLkY8HVB/

It feels a bit strange that this package dependency fails only for Windows, 
especially as neither mvSLOUCH nor any of the packages it imports from depend 
on gtools.

I would be very grateful for assistance.

Best wishes
Krzysztof Bartoszek

Sent with ProtonMail Secure Email.
[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Greg Minshall]

Duncan,

probably you know this one, but as we're sharing, and as i'm a fan, the
=miniCRAN= package has some such functionality, and the results can be
graphed.  e.g.,

require(miniCRAN)
pdb <- pkgAvail()
dg <- makeDepGraph(c("acs", "cdlTools", "maps"), enhances=TRUE,availPkgs=pdb)
plot(dg, legendPosition=c(-1,1),vertex.size=10,cex=0.7)


(though following the arrows, you may need better eyesight than i
possess! :)

cheers, Greg

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Duncan Murdoch]

Thanks!

> On Wed, Jun 2, 2021 at 1:08 PM Duncan Murdoch 
 wrote:

> [...]
>> > search.  It would be nice to know if there's an automatic way to 
answer

>> > the question
>> >
>> > "Why does package xxx appear to require yyy?"

On 02/06/2021 7:10 a.m., Hugh Parsonage wrote:

First I confirmed "gtools" %in% tools::package_dependencies("mvSLOUCH")[[1]]

then

lapply(tools::package_dependencies("mvSLOUCH"),
tools::package_dependencies, recursive = TRUE)

was sufficient to identify the chain.


On 02/06/2021 7:16 a.m., Gábor Csárdi wrote:


One quick way with the dev version of pak:

install.packages("pak", repos = "https://r-lib.github.io/p/pak/dev/;)
pak::pkg_deps_explain("mvSLOUCH", "gtools")
#> mvSLOUCH -> TreeSim -> geiger -> phytools -> gtools

Gabor


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Gábor Csárdi]

On Wed, Jun 2, 2021 at 1:08 PM Duncan Murdoch  wrote:
[...]
> search.  It would be nice to know if there's an automatic way to answer
> the question
>
> "Why does package xxx appear to require yyy?"

One quick way with the dev version of pak:

install.packages("pak", repos = "https://r-lib.github.io/p/pak/dev/;)
pak::pkg_deps_explain("mvSLOUCH", "gtools")
#> mvSLOUCH -> TreeSim -> geiger -> phytools -> gtools

Gabor

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Hugh Parsonage]

First I confirmed "gtools" %in% tools::package_dependencies("mvSLOUCH")[[1]]

then

lapply(tools::package_dependencies("mvSLOUCH"),
tools::package_dependencies, recursive = TRUE)

was sufficient to identify the chain.

On Wed, 2 Jun 2021 at 21:08, Duncan Murdoch  wrote:
>
> On 02/06/2021 6:57 a.m., Hugh Parsonage wrote:
> > mvSLOUCH <--- TreeSim <-- phytools <-- gtools
> >
> > On Wed, 2 Jun 2021 at 20:35, Krzysztof Bartoszek  
> > wrote:
> >>
> >> Thank you. The only problem, as I wrote, is that neither my package, 
> >> mvSLOUCH, nor any package that mvSLOUCH imports from depends on gtools.
> >> In particular nowhere in mvSLOUCH do I use any call to anything from 
> >> gtools nor to any function called combinations.
>
> Hugh, could you describe how you found this dependency chain?  This sort
> of problem comes up now and then, and I've always used a slow manual
> search.  It would be nice to know if there's an automatic way to answer
> the question
>
> "Why does package xxx appear to require yyy?"
>
> Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Duncan Murdoch]

On 02/06/2021 6:57 a.m., Hugh Parsonage wrote:

mvSLOUCH <--- TreeSim <-- phytools <-- gtools

On Wed, 2 Jun 2021 at 20:35, Krzysztof Bartoszek  wrote:


Thank you. The only problem, as I wrote, is that neither my package, mvSLOUCH, 
nor any package that mvSLOUCH imports from depends on gtools.
In particular nowhere in mvSLOUCH do I use any call to anything from gtools nor 
to any function called combinations.


Hugh, could you describe how you found this dependency chain?  This sort 
of problem comes up now and then, and I've always used a slow manual 
search.  It would be nice to know if there's an automatic way to answer 
the question


"Why does package xxx appear to require yyy?"

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] problem with submitting to CRAN (windows)

[Hugh Parsonage]

mvSLOUCH <--- TreeSim <-- phytools <-- gtools

On Wed, 2 Jun 2021 at 20:35, Krzysztof Bartoszek  wrote:
>
> Thank you. The only problem, as I wrote, is that neither my package, 
> mvSLOUCH, nor any package that mvSLOUCH imports from depends on gtools.
> In particular nowhere in mvSLOUCH do I use any call to anything from gtools 
> nor to any function called combinations.
>
> Best wishes
> Krzysztof Bartoszek
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, June 2, 2021 10:25 AM, Hugh Parsonage 
>  wrote:
>
> > Probably a consequence of gtools having build errors
> > (https://cran.r-project.org/web/checks/check_results_gtools.html)
> >
> > I'd recommend reconsidering use of the package until the problems are
> > resolved. In the meantime, put gtools is Suggests for the use of
> > combinations(). Note the base R functions choose and combn that might
> > be sufficient (and certainly more available).
> >
> > On Wed, 2 Jun 2021 at 20:17, Krzysztof Bartoszek krz...@protonmail.ch wrote:
> >
> > > Dear all,
> > > I am trying to submit an update of my mvSLOUCH package to CRAN an am 
> > > getting the following problem from the automatic pretest:
> > > Dear maintainer,
> > > package mvSLOUCH_2.6.5.tar.gz does not pass (yesterday and today) the 
> > > incoming checks automatically, please see the following pre-tests:
> > > Windows: 
> > > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00check.log
> > > Status: 1 ERROR
> > > Debian: 
> > > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Debian/00check.log
> > > Status: OK
> > > The windows error in 
> > > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00install.out
> > > is
> > > ** byte-compile and prepare package for lazy loading
> > > Error: object 'combinations' is not exported by 'namespace:gtools'
> > > Execution halted
> > > ERROR: lazy loading failed for package 'mvSLOUCH'
> > > Interestingly when I today submited to winbuilder (devel) no such issues 
> > > are raised (yesterday the same issue was raised by winbuilder-devel):
> > > https://win-builder.r-project.org/Ou1tDLkY8HVB/
> > > It feels a bit strange that this package dependency fails only for 
> > > Windows, especially as neither mvSLOUCH nor any of the packages it 
> > > imports from depend on gtools.
> > > I would be very grateful for assistance.
> > > Best wishes
> > > Krzysztof Bartoszek
> > > Sent with ProtonMail Secure Email.
> > > [[alternative HTML version deleted]]
> > >
> > > 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

Re: [R-pkg-devel] problem with submitting to CRAN (windows)

[Hugh Parsonage]

Probably a consequence of gtools having build errors
(https://cran.r-project.org/web/checks/check_results_gtools.html)

I'd recommend reconsidering use of the package until the problems are
resolved.  In the meantime, put gtools is Suggests for the use of
combinations().  Note the base R functions choose and combn that might
be sufficient (and certainly more available).

On Wed, 2 Jun 2021 at 20:17, Krzysztof Bartoszek  wrote:
>
> Dear all,
> I am trying to submit an update of my mvSLOUCH package to CRAN an am getting 
> the following problem from the automatic pretest:
> Dear maintainer,
>
> package mvSLOUCH_2.6.5.tar.gz does not pass (yesterday and today) the 
> incoming checks automatically, please see the following pre-tests:
> Windows: 
> 
> Status: 1 ERROR
> Debian: 
> 
> Status: OK
>
> The windows error in 
> https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00install.out
> is
> ** byte-compile and prepare package for lazy loading
> Error: object 'combinations' is not exported by 'namespace:gtools'
> Execution halted
> ERROR: lazy loading failed for package 'mvSLOUCH'
>
> Interestingly when I today submited to winbuilder (devel) no such issues are 
> raised (yesterday the same issue was raised by winbuilder-devel):
> https://win-builder.r-project.org/Ou1tDLkY8HVB/
>
> It feels a bit strange that this package dependency fails only for Windows, 
> especially as neither mvSLOUCH nor any of the packages it imports from depend 
> on gtools.
>
> I would be very grateful for assistance.
>
> Best wishes
> Krzysztof Bartoszek
>
> Sent with ProtonMail Secure Email.
> [[alternative HTML version deleted]]
>
> __
> 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