What is the recommended approach with lintr object_usage_lintr?

[stefanoborini]

using box implies that the symbols "appear" out of thin air, so object_usage_lintr thinks that the entity is undefined. Of course one can define it as a global symbol, but it gets quite boring quickly, and if you don't have a package it won't work anyway, because the lintr is not executing the code anyway.

Is there a better way to ensure that the lintr accepts the symbol as existing?

[klmr]

Unfortunately there’s no good way to make object_usage_linter happy. ‘box’ isn’t the only common use-case which generates issues, and I therefore (unfortunately) recommend disabling object_usage_linter entirely: the linter is fundamentally broken, and I don’t think it is fixable.

The ‘lintr’ package might be accept a patch adding support for ‘box’ (I have previously added ‘box’-specific handling to another linter, and the linter already has special handling for other R packages), but this wouldn’t fix the underlying issues that this linter has for other, common code, so I would still recommend against using it, even patched.

The issue is fundamentally that object_usage_linter (mostly¹) relies on static analysis, and this approach cannot work with a language like R. I am convinced that performing static analysis for object declarations in R is a fools’ errand. The only sensible way to check object usage in R is to perform dynamic analysis, and I do not think that this is approach compatible with ‘lintr’, nor with codetools::objectUsage.

And speaking of codetools::objectUsage, the sensible way forward would be to apply this fix to the ‘codetools’ package, which seems to be effectively unmaintained: there are multiple open bug reports which don’t see any activity from the maintainer; given this, I believe the chance of ‘codetools’ accepting patches to perform ‘box’-specific handling is slim to none. And, again, adding ‘box’ handling wouldn’t solve the wider issue that this package has with any code that uses (directly or indirectly) non-standard evaluation.

---

¹ Actually object_usage_lintr does evaluate assignment expressions, although I would have to trace the code to understand what is actually going on there.

[stefanoborini]

Ok, Thank you.

Funnily enough, I developed in the past my own equivalent for box where you have to use assignment when importing, so object_usage_linter does work as expected. I wanted to drop it in favour of box, but considering what you just said, I'll keep using my own, which works perfectly with no NSE tricks.

[klmr]

Interesting. Don’t you find that too verbose in practice? The predecessor of ‘box’ used explicit assignment for module names — instead of box::use(./mod) you had to write mod = import('mod'), and users (rightly!) complained about the unnecessary redundancy of having to assign to a module name that should be inferred automatically. I imagine that having to explicitly assign all imported names would make the amount of syntactic noise a lot worse.

[stefanoborini]

Not really. it gives me the flexibility to rename the module if needed. It's not different from from a import b as c in python. In R with my package it looks like c <- useonly("a", "b"). Obviously it's redundant if you decide to assign it to b, but what can you do? I prefer to have that flexibility, and have the linter be able to tell me something is wrong, instead of losing both options. I can't afford that. I have a large codebase compared to the general R user, and there are more verbose languages out there (java... cough... java).

[klmr]

Fair enough! To clarify, with box::use you can rename the imported name, you just don’t need to specify the name explicitly if you don’t rename it. Anyway, if you require this lint then that’s obviously moot, although I’m surprised that this particular linter is at all usable for you, since I have found this not to be the case (as discussed initially).