Imported distributions are usable in devtools::test() but fail in devtools::check()

[jthaman]

I have a line in a package I am working on that does some parameter estimation for the inverse gaussian distribution (from the statmod package). The code

     statistic = function(x) {
        as.list(suppressWarnings(
          fitdist(x, "invgauss",
                  start = list(mean = 1, shape = 1)
                  ))$estimate)
    }

And I have @importFrom statmod dinvgauss pinvgauss qinvgauss rinvgauss in my main file.

Now, tests I've defined that use this code work when i run them in the dev session with devtools::test(), but the tests fail using devtools::check(). I get errors such as

Error in `fitdist(x, "invgauss", start = list(mean = 1, shape = 1))`: The  dinvgauss  function must be defined
Backtrace:
    ▆
 1. ├─energyfit::ef(x, d, nsim = 50) at test.R:733:3
 2. └─energyfit:::energyfit.GOFDist(x, d, nsim = 50)
 3.   ├─energyfit:::xform_dist(x, dist)
 4.   └─energyfit:::xform_dist.InverseGaussianDist(x, dist)
 5.     └─dist$statistic(x)
 6.       ├─base::as.list(...)
 7.       ├─base::suppressWarnings(...)
 8.       │ └─base::withCallingHandlers(...)
 9.       └─fitdistrplus::fitdist(x, "invgauss", start = list(mean = 1, shape = 1))

[ FAIL 7 | WARN 0 | SKIP 0 | PASS 392 ]

I've tried a few different things, including changing "invgauss" to statmod::dinvgauss, but that does not work either. I think there is something going on with how fitdist looks for functions that is not interacting correctly the R CMD check. Appreciate if you have any ideas.

[dutangc]

Could you provide a reproducible example? When importing statmod or actuar, it works perfectly.

By the way, if you just need paramater estimates, just use mledist().

[vincenzocoia]

I ran into the same issue developing the famish package.

I think there is something going on with how fitdist looks for functions

Spot on. When fitdistrplus::fitdist() is run, the environment stack it searches for the p/d/q functions is:

1. namespace:fitdistrplus
2. namespace:base
3. Global
4. Package environments attached by the user (with most recently loaded coming first)

Your tests will only pass if the inverse gaussian functions are attached in an environment in Position 4 above (e.g., by attaching the statmod package, or importing the functions into your package) -- but even that will fail if a user doesn't attach your package and instead accesses your functions with ::. Another reason this is less desirable is because it's less safe, because the user has control over what gets found once the Global environment is reached (e.g., maybe another package is loaded after statmod that also has a different implementation of <p/d/q>invgauss()).

TL;DR for @jthaman

I suspect the best you can do is export the functions <p/d/q>invgauss() into your package, but warn the user (a) to be careful that it's your implementation of these functions that gets found from Global, and (b) that they must attach your package (e.g., with library()) rather than using ::.

Package developers

Perhaps it would be useful to add an extra argument to fitdist() that indicates which environment to start looking for <p/d/q>distname. This way, package developers can point to their namespace where they have full control, rather than always starting the search path at namespace:fitdistrplus.

[jthaman]

This seems like an side-effect of the package design, having one argument (a string) from where the package has to lookup a set of d/p/q functions. On one hand, it's user friendly to have one argument for distribution. On the other, I think the bug could be avoided if the user could could directly pass the needed functions to fitdist.

[dutangc]

I have just improved the check of the distr argument. Could you please tell us if it helps?

[vincenzocoia]

This still requires the package providing the distr object to be attached first, rather than accessed by ::, which has two implications:

1. ☠️ A package developer can't use fitdist() because they're supposed to use :: instead of attaching packages.
2. ⚠️ Interactively, someone might get different results based on what they create in Global or the order of attached packages.

For example, the evir package provides dgev(), the density of GEV distributions. Here is a comparison of accessing the density with :: vs attaching the package first with library(evir) (using the version of fitdistr from your recent commit, 5a19d52)

library(fitdistrplus)
#> Loading required package: MASS
#> Loading required package: survival
set.seed(1)
x <- evir::rgev(100, xi = 0.2, mu = 0, sigma = 1)
strt <- list(xi = 0.2, mu = 0, sigma = 1)
fit1 <- try(fitdist(x, distr = evir::dgev, start = strt), silent = TRUE)
fit1
#> [1] "Error in fitdist(x, distr = evir::dgev, start = strt) : \n  Your <distr> argument should be either a character string or a function so that d<distr> exists.Otherwise please wrap it in another function with that name.\n"
#> attr(,"class")
#> [1] "try-error"
#> attr(,"condition")
#> <simpleError in fitdist(x, distr = evir::dgev, start = strt): Your <distr> argument should be either a character string or a function so that d<distr> exists.Otherwise please wrap it in another function with that name.>
library(evir)
fit2 <- fitdist(x, distr = dgev, start = strt)
fit2
#> Fitting of the distribution ' gev ' by maximum likelihood 
#> Parameters:
#>        estimate Std. Error
#> xi    0.1089444 0.07834060
#> mu    0.1180693 0.10409526
#> sigma 0.9188906 0.07917128

^{Created on 2025-11-26 with reprex v2.1.1}

The issue is because distname gets parsed into a length-3 vector and the components "::" and "evir" are removed in this line:

fitdistrplus/R/fitdist.R

Line 33 in 5a19d52

distname <- tail(distname, 1)

[dutangc]

You do not need to attach the package to use it : a simple wrap is enough

dmygev <- evir::dgev
try(fitdist(x, distr = "mygev", start = strt), silent = FALSE)

Most generic functions work except gofstat and quantile.

Nevertheless, it could be an interesting feature to use function directly, but it will change a lot of things in the package. Add to the todolist.

[vincenzocoia]

Great solution! Thanks.