ns-qualify methods in namespace top level

[MichaelChirico]

Closes #1588

@IrshadUlHaq1 I really think this is a {pak} issue, many packages will encounter this issue since it's not something enforced anywhere else in R.

It's also something that's handled inconsistently even within {dbplyr}, which is evidence that tooling to prevent backsliding when fixing this issue is nonexistent:

dbplyr/R/zzz.R

Lines 6 to 8 in 5726930

	methods::setOldClass(c("ident_q", "ident", "character"), ident_q())
	methods::setOldClass(c("ident", "character"), ident())
	methods::setOldClass(c("sql", "character"), sql())

[MichaelChirico]

There are 100s of CRAN packages which don't do methods::-qualification on this function alone (not to mention many other similar issues of assuming the default set of packages under R CMD build):

https://github.com/search?q=org%3Acran+%2F%28%5E%7C%5B%5E%3A%5D%29setOldClass%5C%28%2F+lang%3AR&type=code

[IrshadUlHaq1]

@MichaelChirico What is your advice for me on how to get rid of this once and for all?

Even the install.packages("dbplyr") is throwing the same error.

[MichaelChirico]

Hm, can you report Sys.getenv("R_DEFAULT_PACKAGES")? Maybe you have wound up with set unusually somehow.

[IrshadUlHaq1]

You were right:

Sys.getenv("R_DEFAULT_PACKAGES")
[1] "utils,grDevices,graphics,stats"

R is not explicitly telling me that I have messed up my ~/.Renviron . I commented # the R_DEFAULT_PACKAGES in my ~/.Renviron and everything is up and running normally. Thank you @MichaelChirico for solving this for me, and for teaching me.

[MichaelChirico]

Great, glad it's resolved! I wonder how that happened, it's a really baroque setting!