https://pantsbuild.org/ logo
Join Slack
Powered by
Found some slightly surprising behaviour with `pan...
# general
n
Found some slightly surprising behaviour with 
pantsd
not discovering the existence of a 
go
toolchain which was installed after 
pantsd
was started. From this thread it looks to be known behaviour that the binary lookup is memoized by the daemon to avoid a performance impact on each run, but it does provide slightly poor UX. I wonder if we could improve the UX when filesystem lookups that aren't managed by Pants might have changed -- perhaps by including in the error message the suggestion to run with 
--no-daemon
and then to restart the daemon if that succeeds?
Another thought might be to allow the "happy path" to remain optimized, but to allow the "sad path" (memoized file not found) to be slower by re-checking the filesystem in that specific case?
b
We do that for the Python provider. A process which checks for a file, where the process isn't cached. The happy path is one file check, the sad path does the whole install. Working out nicely. CC @fast-nail-55400
f
Link to code?
b
(sorry for the delay)
h
Certainly that error message improvement is a no-brainer (feel free to send a PR!)
And I think that sad path idea also makes sense
I would go one further - I find it annoying that we re-do binary discovery on every pantsd startup, when it's rare for binary paths to change. So I would like an option to never to rediscovery unless you pass an explicit 
--rehash
flag or something.
b
Techincally, the same thing happens if we put effort into making the daemon as always-on-able as possible.
f
Or provide an intrinsic for rules to monitor absolute file paths.
Which can invalidate when the path changes in some way.
(although the complication for such an intrinsic would be non-local environments)
Open in Slack
PreviousNext
Powered by