You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
I've encountered an issue with the NMF package that complicates building packages that use NMF functions. Specifically, the problem arises when attempting to use NMF functions within my package without explicitly loading the NMF library. Here are the details:
Environment Setup:
NMF is listed as an Imports in the DESCRIPTION file.
NMF functions are imported in the NAMESPACE and functions.R files (I tried both using @import and @importFrom the corresponding functions' roxygen2 tags).
NMF functions are called with the NMF:: prefix (e.g., NMF::nmf()).
Observed Behavior:
When calling my package function that uses NMF functions internally, an error occurs unless library(NMF) is explicitly called beforehand. This behavior is specific to the NMF package and does not occur with other packages.
I've identified an issue in NMF package that makes it very hard to build on top of it. I'm building a package where one of the functions uses the NMF package. The NMF package is an import in the DESCRIPTION file, and it is imported both in the NAMESPACE file and in the functions.R file, where the functions are located (in roxygen2 format @import, @importFrom). I have also tried to call the functions as NMF::nmf() and NMF::coef() instead of just nmf() and coef(), however the error persists.
The error (see below) only gets removed if I explicitly load the library itself, this is, if I have library(NMF) before calling the package function that, internally, uses one of its functions. I have explored a range of possible solutions to avoid forcing users to load this library explicitly when the package is used, but i have not been successful. Notably, this issue only happens with this library, not with any other.
Reproducible Test:
Without attaching NMF, I ran:
> do.call(NMF::nmf, list(matrix(), rank = 1))
This works and returns an error specific to the function:
Error: NMF::nmf - Input matrix x contains at least one null or NA-filled row.
In addition: Warning message:
In min(x, na.rm = TRUE) : no non-missing arguments to min; returning Inf
On the other hand if I just specify nmf directly:
> do.call(nmf, list(matrix(), rank = 1))
Yields:
Error in h(simpleError(msg, call)) :
error in evaluating the argument 'what' in selecting a method for function 'do.call': object 'nmf' not found
Not quite the same error but pointing to the problem -- do.call() looks on the search path (packages that are attached) not in packages that are merely loaded. So, somewhere in the nmf code there is a do.call() that assumes the object is on the search path.
Analysis:
The issue seems to be related to a do.call() usage within the NMF code that assumes the function is on the search path, i.e., the package must be attached via library(NMF).
Suggested Solution:
Please modify the NMF package to ensure functions can be reliably called using the NMF:: prefix, without requiring the package to be attached. This will improve compatibility with packages that import NMF functions, avoiding the need to depend on NMF explicitly.
This is an important issue for the NMF maintainer to fix; otherwise I don't think there's an easy way for to work around when building on top of NMF functions other than Depending on NMF, which is frankly far from ideal (NMF should be an import, just like any other package whose functions are used).
Fixing this issue would greatly enhance the usability of NMF in broader package development and align with best practices for R package dependencies.
The text was updated successfully, but these errors were encountered:
Description:
I've encountered an issue with the NMF package that complicates building packages that use NMF functions. Specifically, the problem arises when attempting to use NMF functions within my package without explicitly loading the NMF library. Here are the details:
Environment Setup:
Imports
in the DESCRIPTION file.@import
and@importFrom
the corresponding functions' roxygen2 tags).NMF::
prefix (e.g.,NMF::nmf()
).Observed Behavior:
When calling my package function that uses NMF functions internally, an error occurs unless
library(NMF)
is explicitly called beforehand. This behavior is specific to the NMF package and does not occur with other packages.Error Traceback:
I've identified an issue in NMF package that makes it very hard to build on top of it. I'm building a package where one of the functions uses the NMF package. The NMF package is an import in the DESCRIPTION file, and it is imported both in the NAMESPACE file and in the functions.R file, where the functions are located (in roxygen2 format @import, @importFrom). I have also tried to call the functions as NMF::nmf() and NMF::coef() instead of just nmf() and coef(), however the error persists.
The error (see below) only gets removed if I explicitly load the library itself, this is, if I have
library(NMF)
before calling the package function that, internally, uses one of its functions. I have explored a range of possible solutions to avoid forcing users to load this library explicitly when the package is used, but i have not been successful. Notably, this issue only happens with this library, not with any other.Reproducible Test:
Without attaching NMF, I ran:
This works and returns an error specific to the function:
On the other hand if I just specify nmf directly:
Yields:
Not quite the same error but pointing to the problem --
do.call()
looks on the search path (packages that are attached) not in packages that are merely loaded. So, somewhere in the nmf code there is ado.call()
that assumes the object is on the search path.Analysis:
The issue seems to be related to a do.call() usage within the NMF code that assumes the function is on the search path, i.e., the package must be attached via library(NMF).
Suggested Solution:
Please modify the NMF package to ensure functions can be reliably called using the NMF:: prefix, without requiring the package to be attached. This will improve compatibility with packages that import NMF functions, avoiding the need to depend on NMF explicitly.
This is an important issue for the NMF maintainer to fix; otherwise I don't think there's an easy way for to work around when building on top of NMF functions other than Depending on NMF, which is frankly far from ideal (NMF should be an import, just like any other package whose functions are used).
Fixing this issue would greatly enhance the usability of NMF in broader package development and align with best practices for R package dependencies.
The text was updated successfully, but these errors were encountered: