-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Make path.readdir() watch the dirents by default
#21341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
.../java/com/google/devtools/build/lib/bazel/repository/starlark/StarlarkRepositoryContext.java
Outdated
Show resolved
Hide resolved
2152df4 to
76e8324
Compare
ahumesky
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approval for the android-related changes
|
sorry about the noise -- there's literally no android-related changes in this PR. GitHub really doesn't handle stacked PRs well. I'll get it sorted eventually, promise... |
43484a5 to
e862424
Compare
76e8324 to
48a9d95
Compare
e862424 to
7d02409
Compare
48a9d95 to
342b1b7
Compare
7d02409 to
0a06ccb
Compare
path.readdir() watch the dirents by default
650dc3e to
8874358
Compare
.../java/com/google/devtools/build/lib/bazel/repository/starlark/StarlarkRepositoryContext.java
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| @StarlarkMethod( | ||
| name = "watch_dir", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT about updating watch() instead to watch the list of directory entries if its target is a directory and the contents of a file if its target is a file? That would spare you a method on the API and I can't immediately identify any case that would be impossible with that setup.
Alternatively, WDYT about extending watch() to have arguments parallel with glob(): watch([<file name>]) would watch a list of specified files, watch(["*.txt"]) would watch every text file and watch(["**"]) (if implemented later), would be a recursive glob. It would also provide a convenient place to add exclude= and other accoutrements as needed. You might even be able to piggyback upon the implementation of glob().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Doing my first review round of the day, I'll assume that you are still working on this change and that's why you haven't replied on this thread)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad -- it look like the changes were more extensive than I thought. Reviewed (mind answering the question above?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw i didn't reply to this thread yesterday because it didn't exist yesterday :P looks like you drafted it but never sent it until today.
but anyway, putting a glob pattern directly in rctx.watch is a bit awkward because you're presumably globbing from the working directory (ie. where the repo is being fetched into). so rctx.watch(['*.txt']) wouldn't make sense, but path.glob(...) probably would.
in any case i don't think we could realistically piggyback onto GlobFunction as it just works too differently: worrying about package boundaries, returning labels instead of paths, not digesting file contents, etc etc.
regarding folding watch_dir into watch: i ended up going with path.readdir instead, which i think it's a more natural api. we could actually still choose to make rctx.watch on a dir be sensitive to dirents in the future, but i don't think it's as important a question now. let me know if you disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad it is then. I'm not the most relaxed and well rested I have ever been...
I have only one concern with the path.readdir() idea: we currently have the read() / watch() dichotomy for files and the "just use readdir() for everything" idea makes it so that we don't have it for directories. I'm not sure it matters, though. At the very least, this decision allows you to postpone the decision about whether you want the recursive watching syntax to be the same as that of globbing (I mean, that's probably like a day, but still...) and teaching readdir() to watch the file system is a pretty obvious win.
src/main/java/com/google/devtools/build/lib/rules/repository/RepoRecordedInput.java
Outdated
Show resolved
Hide resolved
...ava/com/google/devtools/build/lib/bazel/repository/starlark/StarlarkBaseExternalContext.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/bazel/repository/starlark/StarlarkPath.java
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/rules/repository/RepoRecordedInput.java
Outdated
Show resolved
Hide resolved
- Added a new parameter `watch` to `path.readdir()` that allows one to watch for changes in entries under a given directory. - only names are watched; 'entry types' are not. This somewhat matches the return value of `path.readdir()`, which only contains entry names - same restrictions as `rctx.watch()` in terms of which paths can be watched and which cannot; similarly for `mctx`. - Made a big-ish refactor that eliminated the two `RepoRecordedInput.File` subclasses, and pulled the difference into a separate `RepoRecordedInput.RepoCacheFriendlyPath` instead. This new path class is used by the new `RepoRecordedInput.Dirents` as well. Work towards #20952.
da59002 to
551f437
Compare
- Added a new parameter `watch` to `path.readdir()` that allows one to watch for changes in entries under a given directory. - only names are watched; 'entry types' are not. This somewhat matches the return value of `path.readdir()`, which only contains entry names - same restrictions as `rctx.watch()` in terms of which paths can be watched and which cannot; similarly for `mctx`. - Made a big-ish refactor that eliminated the two `RepoRecordedInput.File` subclasses, and pulled the difference into a separate `RepoRecordedInput.RepoCacheFriendlyPath` instead. This new path class is used by the new `RepoRecordedInput.Dirents` as well. Work towards #20952. Closes #21341. PiperOrigin-RevId: 607772207 Change-Id: Ibba2b3389acd23e0a703818fec2cd58321a9b896
- Added a new parameter `watch` to `path.readdir()` that allows one to watch for changes in entries under a given directory. - only names are watched; 'entry types' are not. This somewhat matches the return value of `path.readdir()`, which only contains entry names - same restrictions as `rctx.watch()` in terms of which paths can be watched and which cannot; similarly for `mctx`. - Made a big-ish refactor that eliminated the two `RepoRecordedInput.File` subclasses, and pulled the difference into a separate `RepoRecordedInput.RepoCacheFriendlyPath` instead. This new path class is used by the new `RepoRecordedInput.Dirents` as well. Work towards #20952. Closes #21341. PiperOrigin-RevId: 607772207 Change-Id: Ibba2b3389acd23e0a703818fec2cd58321a9b896
watchtopath.readdir()that allows one to watch for changes in entries under a given directory.path.readdir(), which only contains entry namesrctx.watch()in terms of which paths can be watched and which cannot; similarly formctx.RepoRecordedInput.Filesubclasses, and pulled the difference into a separateRepoRecordedInput.RepoCacheFriendlyPathinstead. This new path class is used by the newRepoRecordedInput.Direntsas well.Work towards #20952.