[R-pkg-devel] Warnings with reverse dependencies in mutually dependend packages?

I maintain two packages, which are kind of "mutually depending" on each 
other. Now I have updated package A, like to submit it - however, it 
produces warnings (in my package B) when doing the reverse dependency 
check. Yet I cannot fix the warnings in package B and submit it, since 
it relies on new functions of package A, which has to be submitted 
first... and so on.

My question: is it ok to submit package A, saying that I'm aware of the 
warnings in package B, which are already fixed, and that I would submit 
package B after package A has been released on CRAN?

On 25/08/2015 9:48 AM, Daniel L?decke wrote:

I maintain two packages, which are kind of "mutually depending" on each 
other. Now I have updated package A, like to submit it - however, it 
produces warnings (in my package B) when doing the reverse dependency 
check. Yet I cannot fix the warnings in package B and submit it, since 
it relies on new functions of package A, which has to be submitted 
first... and so on.

My question: is it ok to submit package A, saying that I'm aware of the 
warnings in package B, which are already fixed, and that I would submit 
package B after package A has been released on CRAN?

It's not clear to me whether both packages will work in the time when
you've updated A but not B.  If not, this is a bad idea:  users of your
packages will be left with broken systems.

If you want to make incompatible changes to A, and B is the only reverse
dependency, then you could update both at once.  When you submit the
first one, say that the other submission is coming as well.

You should also be making use of version specifiers in your DESCRIPTION
file.  If B version 2 won't work with A version 1, then say that, via

Depends:  A (>=2.0.0)

Duncan Murdoch

Thanks for the quick reply. Yes, both packages will work. It's just that I renamed some functions in package B (e.g. `get_val_labels` to `get_labels`) and calling `get_val_labels` now throws a "deprecated"-warning (I'm using `.Deprecated` in that function call).

Thus, checking reverse dependencies, my current package A on CRAN will of course give warnings due to calling old function names, however, I already updated package A accordingly, which will no longer throw warnings once both packages A and B are updated on CRAN.

Also, I'm already using version identifiers in my DESCRIPTION file, so depend packages with correct required versions should be installed.

I guess it's not important, but the packages I'm talking about are `sjPlot` and `sjmisc`.

Best
Daniel

Am 25.08.2015 um 16:56 schrieb Duncan Murdoch <murdoch.duncan at gmail.com>:

On 25/08/2015 9:48 AM, Daniel L?decke wrote:

I maintain two packages, which are kind of "mutually depending" on each 
other. Now I have updated package A, like to submit it - however, it 
produces warnings (in my package B) when doing the reverse dependency 
check. Yet I cannot fix the warnings in package B and submit it, since 
it relies on new functions of package A, which has to be submitted 
first... and so on.

My question: is it ok to submit package A, saying that I'm aware of the 
warnings in package B, which are already fixed, and that I would submit 
package B after package A has been released on CRAN?

It's not clear to me whether both packages will work in the time when
you've updated A but not B.  If not, this is a bad idea:  users of your
packages will be left with broken systems.

If you want to make incompatible changes to A, and B is the only reverse
dependency, then you could update both at once.  When you submit the
first one, say that the other submission is coming as well.

You should also be making use of version specifiers in your DESCRIPTION
file.  If B version 2 won't work with A version 1, then say that, via

Depends:  A (>=2.0.0)

Duncan Murdoch

Daniel,

That whole setup sounds somewhat messy.  I would either

-  merge sjPlot and sjmisc, possibly into sjPlot and just deprecate the
   then-redundant sjmisc

-  define sjbase, upload it, and have both sjPlot and sjmisc depend on it

Dirk


-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org