From kirill.mueller at ivt.baug.ethz.ch  Fri Dec 16 18:34:42 2016
From: kirill.mueller at ivt.baug.ethz.ch (=?UTF-8?Q?Kirill_M=c3=bcller?=)
Date: Fri, 16 Dec 2016 18:34:42 +0100
Subject: [Rd] Upgrading a package to which other packages are LinkingTo
In-Reply-To: <22612.5114.200686.241246@max.nulle.part>
References: <e04b65b6-bb5e-b0ae-9c30-761c20ad24a4@ivt.baug.ethz.ch>
	<341cb7cf-03f6-d70d-464f-a87c77617c9b@gmail.com>
	<22611.60978.786479.630863@max.nulle.part>
	<8555d7b8-e2da-38f7-f133-9e7d46cf74b6@gmail.com>
	<22612.2793.857104.239264@max.nulle.part>
	<52a8bf02-b3d0-51a4-3bb3-162758156623@gmail.com>
	<22612.5114.200686.241246@max.nulle.part>
Message-ID: <491cc6a5-19c4-4b81-8ec6-e64abfdabacd@ivt.baug.ethz.ch>

Thanks for discussing this.

On 16.12.2016 17:19, Dirk Eddelbuettel wrote:
> On 16 December 2016 at 11:00, Duncan Murdoch wrote:
> | On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote:
> | > On 16 December 2016 at 10:14, Duncan Murdoch wrote:
> | > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote:
> | > | >
> | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote:
> | > | > | Perhaps the solution is to recommend that packages which export their
> | > | > | C-level entry points either guarantee them not to change or offer
> | > | > | (require?) version checks by user code.  So dplyr should start out by
> | > | > | saying "I'm using Rcpp interface 0.12.8".  If Rcpp has a new version
> | > | > | with a compatible interface, it replies "that's fine".  If Rcpp has
> | > | > | changed its interface, it says "Sorry, I don't support that any more."
Sounds good to me, I was considering something similar. dplyr can simply 
query Rcpp's current version in .onLoad(), compare it to the version at 
installation time and act accordingly.
> | > | >
> | > | > We try. But it's hard, and I'd argue, likely impossible.
> | > | >
> | > | > For example I even added a "frozen" package [1] in the sources / unit tests
> | > | > to test for just this. In practice you just cannot hit every possible access
> | > | > point of the (rich, in our case) API so the tests pass too often.
> | > | >
> | > | > Which is why we relentlessly test against reverse-depends to _at least ensure
> | > | > buildability_ from our releases.
> | >
> | > I meant to also add:  "... against a large corpus of other packages."
> | > The intent is to empirically answer this.
> | >
> | > | > As for seamless binary upgrade, I don't think in can work in practice.  Ask
> | > | > Uwe one day we he rebuilds everything every time on Windows. And for what it
> | > | > is worth, we essentially do the same in Debian.
> | > | >
> | > | > Sometimes you just need to rebuild.  That may be the price of admission for
> | > | > using the convenience of rich C++ interfaces.
> | > | >
> | > |
> | > | Okay, so would you say that Kirill's suggestion is not overkill?  Every
> | > | time package B uses LinkingTo: A, R should assume it needs to rebuild B
> | > | when A is updated?
> | >
> | > Based on my experience is a "halting problem" -- i.e. cannot know ex ante.
> | >
> | > So "every time" would be overkill to me.  Sometimes you know you must
> | > recompile (but try to be very prudent with public-facing API).  Many times
> | > you do not. It is hard to pin down.
I'd argue that recompiling/reinstalling B is cheap enough and the safest 
option. So unless there is a risk, why not simply do it every time A 
updates? This could be implemented with a perhaps small change in R: 
When installing A, treat all packages that have A in both LinkingTo and 
Imports as dependencies that need to be reinstalled.


-Kirill
> | >
> | > At work we have a bunch of servers with Rcpp and many packages against them
> | > (installed system-wide for all users). We _very really_ needs rebuild.
>
> Edit:  "We _very rarely_ need rebuilds" is what was meant there.
>   
> | So that comes back to my suggestion:  you should provide a way for a
> | dependent package to ask if your API has changed.  If you say it hasn't,
> | the package is fine.  If you say it has, the package should abort,
> | telling the user they need to reinstall it.  (Because it's a hard
> | question to answer, you might get it wrong and say it's fine when it's
> | not.  But that's easy to fix:  just make a new release that does require
>
> Sure.
>
> We have always increased the higher-order version number when that is needed.
>
> One problem with your proposal is that the testing code may run after the
> package load, and in the case where it matters ... that very code may not get
> reached because the package didn't load.
>
> Dirk
>



[Rd] Upgrading a package to which other packages are LinkingTo
=?UTF-8?Q?Kirill_M=c3=bcller?=