Diagnostics: Linter shows problems when using symbols from packages not yet loaded

[dfalbel]

Positron Version: 2023.09.0 (Universal) build 139
Code - OSS Version: 1.79.0
Commit: 7f5dc8c
Date: 2023-09-13T02:39:00.220Z
Electron: 22.3.10
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Darwin arm64 22.6.0

Steps to reproduce:

Write something like this in the file pane, without actually executing the code:

library(tidyverse)

select()
read_lines()
filter()
summarise()
map()

I know this is a hard problem because there's no easy way to know what packages will be loaded in the script. But it feels weird to see the linter display a bunch of problems when opening a file containing calls like this:

What did you expect to happen?

Maybe this linting rule should be disabled by default on non-package projects? Or if there are library()/require() calls in the script?

[jmcphers]

Agree that this is annoying. It mostly drives me nuts with ggplot commands.

If the script contains library(x) calls for a package x which is installed, we can peek into the x package to see what symbols it defines, so that those symbols don't get marked as missing. However, a significant challenge with these systems in R is that you have to load the namespace in order to get the diagnostics right, and people are mostly not happy when namespaces are loaded implicitly.

If the script contains library(x) calls for a package x which is not installed, we could turn off symbol linting for that file and instead offer to install the missing library. RStudio has a feature to detect packages that aren't installed and offer to install them, and it's very popular.

An IDE which shall remain nameless shows these linter errors even if the package is installed, and offers a quick-fix button next to the error that runs library(x) when clicked. This is arguably a little noisy but also arguably correct since it's true that the code cannot be run until you run library(x).

A related issue is that even after you run the library() functions the lint doesn't go away. That work is tracked in posit-dev/ark#83.

[jennybc]

However, a significant challenge with these systems in R is that you have to load the namespace in order to get the diagnostics right, and people are mostly not happy when namespaces are loaded implicitly.

I think of this as another example where we need some internal, sandboxed R session, matching the current runtime (R version, libpaths, etc.), where we can do stuff like this without messing with the user's actual R session.

[kevinushey]

RStudio has some support for this -- it basically looks at what packages are used in a project, and then runs a separate R process that loads and inspects those packages. See:

https://github.com/rstudio/rstudio/blob/1fb8c970fb212301ce2e91834f2b68deb7827169/src/cpp/session/modules/SessionCodeTools.R#L1361-L1450

[juliasilge]

This came up during usability testing with @simonpcouch today, and he convinced me that this is a pretty significant blocker for feeling productive and focused while using Positron, especially combined with how noisy the UI is when you have 🚨 PROBLEMS🚨 .

The UI signals to you that you have problems in a file both with color (filename changes color) and the Problems pane, at the least, but it is very common to end up with these kinds of problems. For example, in package development, a common cycle is to change code, load_all(), then run code. You have PROBLEMS for the part of this cycle that takes up the most of your actual time.