Fix for new shapr package structure

[martinju]

Hi

Thanks for creating a plotting wrapper for the shapr. We are currently working on a complete restructuring of the package with lots of new functionality. This also involves breaking changes as we have moved away from the two-function case with user calling shapr() + explain() to doing everything in explain(). Also the output form explain() got new names.

The new version of shapr (1.0.0) is available for here: https://github.com/NorskRegnesentral/shapr
(and installed through remotes::install_github("NorskRegnesentral/shapr")

This PR fixes changes shapviz.shapr to follow the new structure and your vignette example.
Due to changes in the package swapping the order of function calls involving randomess, the results are close to, but not identical to the ones with the cran version of shapr. However, with a slight modification of the calls to shapr, disabling this randomness, I have verified the results are identical. See the last part of https://github.com/martinju/shapviz/blob/fix_new_shapr/testscript_to_be_deleted.R for details.

Also, I suggest adding shapr (>= 1.0.0) to either Suggests of Enchanes in your DESCRIPTION file such that we are able to track usage of our package and detect cases like this automatically in the future :-)

We are aiming at a CRAN release of shapr 1.0.0 within the next few weeks. I suggest confirming this PR as soon as possible, and then push a new CRAN release of shapviz with this code once shapr 1.0.0 has made it to CRAN. I will notify you when the CRAN team is happy.

[mayer79]

Thanks for the PR, looks good to me! The plan is clear: First {shapr} to CRAN, then {shapviz} to CRAN. I might decide against the extra dependency to {shapr} in {shapviz}, but that is a minor change in the plan :-).

Later on in the year, I am actually planning some improvements in the SHAP dependency plots, but that won't affect {shapr}.

[martinju]

Great, thanks for the quick response!

The plan is clear: First {shapr} to CRAN, then {shapviz} to CRAN

I have not handled broken packages before, but, yes I do think this is the appropriate way to do it.

I might decide against the extra dependency to {shapr} in {shapviz}, but that is a minor change in the plan :-).

That is of course up to you to decide, but I believe it is highly uncommon to user a package not mentioned in DESCRIPTION. I am actually surprised the CRAN team allowed it in the first place. As I am sure you know, adding a package to suggests or enhances, will not make them required to use your package.
As mentioned above, listing packages in DESCRIPTION provides an insurance for both me developing shapr that we detect it if changes in shapr break something in your package, and for you developing shapviz to have the cran team notify you if changes in other packages breaks something in yours.
If your are still not convinced, I recommend this reading:
https://r-pkgs.org/dependencies-mindset-background.html :-)

[mayer79]

@martinju The new {shapr} release looks great, and the update of {shapviz} is on its way to CRAN.

Let us decide in a later release whether to add {shapr} to "enhances". I definitively get your points.

[martinju]

Excellent, thanks!