Summary: With this, we start watchman on entry to the repository as a
transient, background systemd user service. We also set WATCHMAN_SOCK to the
file path of the socket it creates for any clients like buck to find it. At
this point, buck should be completely configured to talk with watchman directly
with no further intervention. You can see its status with:
systemctl --user status watchman.service
The intent here is that watchman is better at keeping track of file changes
more efficiently, and will overall better integrate with systems like Sapling
and EdenFS in the long run. It also has a separate, more flexible file ignore
policy than Buck does by default; by default, unlike a VCS, buck tries to track
all files with very few exceptions and so ignores .gitignore; it often ends
up picking up spurious 'cargo build' artifacts during development as a result
e.g. when rust-analyzer creates target/ directories from vscode, buck build
and watchman will see these file changes when it shouldn't bother tracking
them. Not to mention all other kinds of build products.
By integrating buck with watchman and a proper .watchmanconfig, these files
can be and directories can be better ignored in the long run, though it does
result in a bit of repetition between this and .gitignore files, unfortunately.
Currently, there's no way to stop the service on direnv unload, not that we
would want to (it wouldn't be safe with multiple instances in a directory). So
it just lingers for as long as needed, for now, and can be deleted with:
systemctl --user stop watchman.service
For now, this only kicks in if the user has touch'd the .use_watchman file in
the root of the repository.
Test Plan: touch .use_watchman, then touch .envrc to reset the environment,
and watch that the daemon is started by direnv. Do it again, and see it was not
started (because it exists.) Kill it, do it over again, and see it still works.
Finally, run many parallel cargo build actions while running buck build ...
over and over again to ensure it doesn't pick up cargo files anymore.
Stack created with Sapling. Best reviewed with ReviewStack.
7
feat(direnv): start watchman service on dir entry
Summary: With this, we start watchman on entry to the repository as a transient, background systemd user service. We also set WATCHMAN_SOCK to the file path of the socket it creates for any clients like buck to find it. At this point, buck should be completely configured to talk with watchman directly with no further intervention. You can see its status with:
The intent here is that watchman is better at keeping track of file changes more efficiently, and will overall better integrate with systems like Sapling and EdenFS in the long run. It also has a separate, more flexible file ignore policy than Buck does by default; by default, unlike a VCS, buck tries to track all files with very few exceptions and so ignores
.gitignore; it often ends up picking up spurious 'cargo build' artifacts during development as a result e.g. when rust-analyzer creates target/ directories from vscode,buck buildand watchman will see these file changes when it shouldn't bother tracking them. Not to mention all other kinds of build products.By integrating buck with
watchmanand a proper.watchmanconfig, these files can be and directories can be better ignored in the long run, though it does result in a bit of repetition between this and .gitignore files, unfortunately.Currently, there's no way to stop the service on direnv unload, not that we would want to (it wouldn't be safe with multiple instances in a directory). So it just lingers for as long as needed, for now, and can be deleted with:
For now, this only kicks in if the user has touch'd the
.use_watchmanfile in the root of the repository.Test Plan:
touch .use_watchman, thentouch .envrcto reset the environment, and watch that the daemon is started by direnv. Do it again, and see it was not started (because it exists.) Kill it, do it over again, and see it still works. Finally, run many parallelcargo buildactions while runningbuck build ...over and over again to ensure it doesn't pick up cargo files anymore.