Can groundhog be used within another package?

[fcampelo]

Hi all, thanks for the great package!

Not an actual issue but a curiosity (and maybe a feature request?): can groundhog be used in package development, i.e., to make sure that specific versions of package dependencies (listed, e.g. under Imports) are the ones being called within a given package? This would be a fantastic contribution to reduce package sensitivity to version changes in upstream dependencies.

Cheers,

[urisohn]

To make sure I understand: You develop pkgA which depends on pkgB. You want to be able to specify, within pkgA, which version of pkgB is used, so that pkgA may be released today, but the version of pkgB it depends on is not the current one, but one available in the past.

This is not possible with 'groundhog' and I would advise against it due to compatibility problems with other packages. Say pkgC, managed by another person, also depends on pkgB and a user wants both pkgA and pkgC, when they try to load both pkgA and pkgC they cannot load two different versions of pkgB, the current one needed by C, and the old one needed by A, and thus A&C would not be compatible.

It seems that one has to ensure, when releasing a new package, that it is compatible with all its dependencies as current on the release data. If it is, groundhog will ensure they remain compatible 'forever'

If i misunderstood the question let me know

[fcampelo]

Hi @urisohn ,

Thanks a lot for the response. I believe you understood the main idea correctly (maybe I should have expressed it more clearly): the question was "_if I develop a package(pkgA) that depends on another package (pkgB), can I use groundhog to make sure that (pkgA) always calls functions from a specific version of (pkgB) in its internal workings, without it affecting the version that is visible in the main R session?_". Perhaps it was a somewhat silly question on my part.

I like your alternative suggestion, but that would require that all dependencies of (pkgA) be loaded explicitly using groundhog.library() before the user called library(pkgA), right? The problem I'm currently facing is not lack of compatibility at time of development - I totally agree that a package must be compatible with all its dependencies at the time of release. Instead, the issue is having a dependence structure with too many upstream packages, which makes mine quite susceptible to being periodically broken due to version changes from other developers.

In any case, thanks a lot for your answer - and for the great package! 👍

Cheers,