[Rd] A demonstrated shortcoming of the R package management system

[Dirk Eddelbuettel]

Hi Ivan,

I usually 'mentally applaud' when reading your replies on list but not here.

On 7 August 2023 at 16:15, Ivan Krylov wrote:
| SeuratObject 4.1.3. The breakage definitely exists, but not on the
| source package level.

You seem to overlook that a large part of the R Universe only works off
source distributions and, as one cannot run source, builds binaries off them.

The breakage is real.

Also implying our packages in question would not reverse-dependency check is
not helpful. Of course they do.

[ And as an illustrative aside, part of the 'third problem I mentioned in my
initial email concerning Debian is that eg (some) Debian maintainers insist
on autopkgtests (a good idea in theory) and get terribly hung up when they
manage to mismatch package relations (ie 'skew' from CRAN -- while that is in
part self-imposed) some troubles are real and eg Matrix 1.6.0 only got to
'testing' now after release manager intervention. (And no Mikael, that was
not Seurat related but thanks for the tip in your email, already passed it
on.)  Of course we have other issues too there with eg exotic non-CRAN
platforms (now including i386) breaking. But that is outside of this thread.
Thanks for bearing with me). ]

Dirk

| 
| It may also not be easy for the package developer to notice breaking a
| binary package while performing reverse dependency checks, in time to
| add such a notice to their package. The recommended way to do that is
| tools::check_packages_in_dir(), which works on source packages.
| 
| Would it help to reframe the problem in terms of binary packages
| acquiring dependency constraints that are more strict than those of the
| corresponding source packages? If a package that imports S4 classes
| from another package and thus ends up caching their definitions, R
| could compute a hash of the classes being imported, store it together
| with the installed package and complain noisily if the hash doesn't
| match later at load time. This could be used to detect such problems
| automatically (but could also result in false positives!).
| 
| This is not the only way a binary package could accidentally depend on
| internals of another binary package. I remember reading about (but
| cannot find it now!) some packages "importing" a function from ggplot2
| (I think) by assigning it into their namespace:
| 
|  foo <- ggplot2::useful_function
| 
| This worked for quite a while, but later broke because
| ggplot2::useful_function called an internal function which ceased to
| exist in a new version of ggplot2. This is arguably a bug and probably
| even harder to track, but are there any other ways to catch a "binary
| dependency" for a package?
| 
| -- 
| Best regards,
| Ivan

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org