Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import advice generates unfortunate NOTE in R CMD check #203

Closed
vspinu opened this issue Jan 10, 2015 · 4 comments
Closed

Import advice generates unfortunate NOTE in R CMD check #203

vspinu opened this issue Jan 10, 2015 · 4 comments

Comments

@vspinu
Copy link

vspinu commented Jan 10, 2015

From namespace/import-r:

If you are using just a few functions from another package, my recommendation is to note the package name in the Imports: field of the DESCRIPTION file and call the function(s) explicitly using ::, e.g., pkg::fun().

This generates CMD check note Namespace in Imports field not imported from .... For example in the current lubridate:

* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘memoise’
  All declared Imports should be used.

To silence this note one would need to use @importFrom pkg func at least once in the package.

@hadley
Copy link
Owner

hadley commented Jan 10, 2015

That's because you've created a build-time dependency not a run time dependency. (Use it in a function to see why)

I'm not sure what the best solution is. This action is fundmentally dangerous because it uses the memorise package that you have installed when running R CMD build, not the package loaded when the user loads your package

@vspinu
Copy link
Author

vspinu commented Jan 10, 2015

That's because you've created a build-time dependency not a run time dependency.

Yeh. That's indeed the reason for it. Thanks.

I'm not sure what the best solution is.

I can think of two solutions. Either to use an unlocked environment inside the package to hold the function or implement a simple caching mechanism inside this function and abandon memoise dependency.. As memoise is used only once in the package I will probably go with the second.


Any ideas about where the other NOTE comes from?

* checking dependencies in R code ... NOTE
Package in Depends field not imported from: ‘methods’
  These packages need to be imported from (in the NAMESPACE file)
  for when this namespace is loaded but not attached.

I don't see the point of this message;methods is always attached.

It seems to be a common issue with methods which some people fix by importing the whole method package. An outrageous solution as all exported functions from methods are effectively copied into each of such packages.

@hadley
Copy link
Owner

hadley commented Jan 10, 2015

Methods is not attached when you use Rscript (ridiculous but true). Importing the whole package is fine (if a bit inelegant) - the copies are just pointers, not deep. You can just important individual methods of you want to avoid that.

@vspinu
Copy link
Author

vspinu commented Jan 10, 2015

Methods is not attached when you use Rscript (ridiculous but true).

Aha!

Importing the whole package is fine (if a bit inelegant) - the copies are just pointers, not deep. You can just important individual methods of you want to avoid that.

Yeh. I did the latter. Thanks.

@vspinu vspinu closed this as completed Jan 10, 2015
maurolepore added a commit to maurolepore/datos that referenced this issue Apr 12, 2020
Relates to cienciadedatos#108

Avoid note as in hadley/r-pkgs#203
While inelegant, this seems to be the recommended solution.
It solves the note in the subject of this commit for most
of the problematic platforms. There is still one platform
I'm not sure about (details below). But in any case, this
commit brings us closer to the goal.

DETAILS

CRAN's check results at
https://cran-archive.r-project.org/web/checks/2020/2020-02-20_check_results_datos.html

I no longer see the note on rhub with:
Platform:	Fedora Linux, R-devel, clang, gfortran
https://builder.r-hub.io/status/datos_0.2.0.tar.gz-d06dd13075724881be4ee9da953cd7ce

But seems to persist on rhub with
Platform:	Debian Linux, R-devel, GCC
https://builder.r-hub.io/status/datos_0.2.0.tar.gz-109732efb4d34774b3d1124954b63ba4
Maybe this result is from an older run. The results take a long
time to arrive and older and later runs might get mixed.
maurolepore added a commit to maurolepore/datos that referenced this issue Apr 19, 2020
Relates to cienciadedatos#108

Avoid note as in hadley/r-pkgs#203
While inelegant, this seems to be the recommended solution.
It solves the note in the subject of this commit for most
of the problematic platforms. There is still one platform
I'm not sure about (details below). But in any case, this
commit brings us closer to the goal.

DETAILS

CRAN's check results at
https://cran-archive.r-project.org/web/checks/2020/2020-02-20_check_results_datos.html

I no longer see the note on rhub with:
Platform:	Fedora Linux, R-devel, clang, gfortran
https://builder.r-hub.io/status/datos_0.2.0.tar.gz-d06dd13075724881be4ee9da953cd7ce

But seems to persist on rhub with
Platform:	Debian Linux, R-devel, GCC
https://builder.r-hub.io/status/datos_0.2.0.tar.gz-109732efb4d34774b3d1124954b63ba4
Maybe this result is from an older run. The results take a long
time to arrive and older and later runs might get mixed.
psychelzh added a commit to psychelzh/tarflow.iquizoo that referenced this issue Dec 17, 2023
See hadley/r-pkgs#203 for more detailed recommendations

Signed-off-by: Liang Zhang <psychelzh@outlook.com>
psychelzh added a commit to psychelzh/tarflow.iquizoo that referenced this issue Dec 17, 2023
See hadley/r-pkgs#203 for more detailed recommendations

Signed-off-by: Liang Zhang <psychelzh@outlook.com>
PietrH added a commit to inbo/camtrapdp that referenced this issue May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants