CODEWITHSUNDEEP
rr-packagedbplyrname-collision
MichaelChirico
MichaelChirico

Reputation: 34733

Dealing with intentional NAMESPACE conflicts

I'm writing a package that imports (and uses) both SparkR::sql and dbplyr::sql. The other relevant questions involve unintentional collisions brought on my haphazard importing.

In my NAMESPACE I have:

importFrom(dbplyr, sql)
importFrom(SparkR, sql)

Both of these functions are used in the script and, being aware of the conflict, I'm sure to always prefix the package name:

dbplyr::sql(...)
SparkR::sql(...)

Nevertheless, I get an import replacement warning when building/checking the package:

Warning: replacing previous import ‘dbplyr::sql’ by ‘SparkR::sql’ when loading ‘my_pkg’

What I see in Writing R Extensions seems to be the following:

If a package only needs a few objects from another package it can use a fully qualified variable reference [foo::f] in the code instead of a formal import... This is slightly less efficient than a formal import and also loses the advantage of recording all dependencies in the NAMESPACE file (but they still need to be recorded in the DESCRIPTION file). Evaluating foo::f will cause package foo to be loaded, but not attached, if it was not loaded already—this can be an advantage in delaying the loading of a rarely used package.

Am I right that the takeaway of this / best practice is to:

Upvotes: 1

Views: 367

Answers (1)

Ralf Stubner
Ralf Stubner

Reputation: 26823

I have always followed this advice:

It’s common for packages to be listed in Imports in DESCRIPTION, but not in NAMESPACE. In fact, this is what I recommend: list the package in DESCRIPTION so that it’s installed, then always refer to it explicitly with pkg::fun().

In your case:

  • Remove both importFrom
  • Keep both packages in Imports:
  • Use dbplyr::sql and SparkR::sql

My main motivation here is consistency: Even without any name clashes I want to always use the full name to make it clear when reading the code where some function comes from. If I do not use importForm and forget about using the full name at one place, R CMD ckeck will catch that. I value this code clarity higher than the (perceived) advantage of collecting dependencies in two places: DESCRIPTION and (more explicitly) NAMESPACE.

Upvotes: 3

Related Questions