bazel symlinks confuse the live-updater

[nicks]

When I was trying to get live_update to work with Bazel, it was getting confused with where the binary live due to symlink directories in the binary path.

There's probably a Tilt bug here, I just need to isolate a repro case

[nicks]

OK, here's the problem:

• on MacOS, bazel-bin/path/to/binary symlinks to a file under /private/var/tmp
• FSEvents reports the file changes as /private/var/tmp, even when the watch is targeting ./bazel-bin

The obvious solution is to realpath everything everywhere, but this has its own set of problems...

• symlinks can change, so you run into problems depending on when you run the realpath (e.g., the first time i tried this approach, i ran into problems because the bazel-bin symlink didn't exist when Tilt first started)
• some projects have very long deps lists (see: https://github.com/tilt-dev/tilt/issues/3456), and it's probably not reasonable to realpath 4K files on every change

[nicks]

OK, I have a workaround for this that fixes the immediate problem, but isn't super satisfying.

Here's an example bazel of "building up" a bazel project for live-update: https://github.com/tilt-dev/tilt-example-bazel

If you have Tilt run str(local('bazel info bazel-bin')).strip(), it will give you the "real" directory, which you can watch for live-updates instead of the symlink https://github.com/tilt-dev/tilt-example-bazel/blob/main/3-recommended/Tiltfile#L29

I'll leave this issue open because it might still make sense to fix this, but it's certainly less critical now that there's an easy workaround

[psigen]

Unfortunately, I think this is still a blocking issue. In the case of python targets, the files in the bazel-bin directory are actually just symlinks to the source tree. That means that there is no non-symlink-based runfiles directory that can be watched -- the above workaround still ends up filled with symlinks.

[jscheel]

Yep, I've un into this as well