Description
pyre: 0.0.7 (from pip list)
While the documentation does note that pyre can be run either as a server or as a one-off check, pyre's behaviour when a user misunderstands this leads to further confusion for the user rather than
Specifically, consider the following:
$ python3 -m venv venv
$ . venv/bin/activate
$ pip install pyre-check python-dateutil
$ cat thing.py
import dateutil.parser
$ pyre
ƛ Server not running at `.`. Starting...
ƛ Server initializing...
ƛ Found 1 type error!
thing.py:1:0 Undefined import [21]: Could not find a module corresponding to import `dateutil.parser`.
(Consider that the user might have more than just the one type error at this point, and that they therefore might not have actually seen the lines about starting a server)
At this point the user might realise (after reviewing the docs for third party stubs, or finding #43 (comment) etc.) that they need to add --search-path to enable the third party stubs:
$ pyre --search-path=path/to/typeshed/third-party
thing.py:1:0 Undefined import [21]: Could not find a module corresponding to import `dateutil.parser`.
This output is quite confusing. The user believes that they have corrected for the lack of search-path, yet are still seeing errors.
It would have been useful on the second run, which appears to only check with the running server for its results and not alter the search-path to have errored about the search-path being specified but unused.
An ideal error might be something like this:
$ pyre --search-path=path/to/typeshed/third-party
Pyre server is already running with a different search path.
To change the search path in use, run
pyre --search-path=path/to/typeshed/third-party restart
$
This would help the user better understand their interactions with pyre as a client-server program as well as provide a solution to their immediate problem.
I'm assuming that the client is able to detect what search path is being used by the server and thus only emit this message when the search path is different. That would allow tooling to specify the (unchanged) search path on the command line. There is still a potential for some confusion from users around this, I'd be in favour of always erroring about unusable parameters if there's no way to check their current values.
I'd be in favour of something like this applying to all the command line options that experience a similar behaviour (i.e: are currently accepted but might not actually be used).