direnv: allow configuring extra files to watch from devenv.nix #1186
Conversation
|
Question on the side: will |
direnvrc
Outdated
| # Watch extra files configured in devenv.nix | ||
| if [[ -f "$extra_files_watchlist" ]]; then | ||
| for file in $(cat "$extra_files_watchlist"); do | ||
| files_to_watch+=("$file") |
There was a problem hiding this comment.
Would probably just call nix_direnv_watch_file here to prevent files_to_watch getting bigger resulting in heavier checksum and amount of profiles getting bigger. But not sure if this is really a problem.
There was a problem hiding this comment.
Hmm, maybe. So the idea is to cache the evaluated shell and skip re-evaluation next time. The question is whether we want the watched files to form part of the cache?
For example, if you have a requirements.txt and change the version of a package, would you like that to be a new cache key? Or overwrite the existing one? I think you'd just want the latter 🤔
There was a problem hiding this comment.
Not sure, would it also have separate nix caches? Switching between branches with different versions is not that uncommon and if nix cache could be reused it would be almost instantaneous, which would be nice. On the other hand this use case is not that super common that it needs to be a big concern. I'd say separate profiles if nix cache can be reused, if not just overwrite the existing cache?
Did some research/testing about shasum overhead, and as long as the amount of files and size of these files doesn't get completely out of control, it should have almost no impact. It would even be possible to skip checking files last edit date completely when shasumming everything (but leaving that on is probably nicer).
|
@sandydoo Thanks for taking the time to implement this |
|
|
||
| # Watch any extra files configured via `config.direnv.watchFiles` for changes | ||
| # This picks up new files and reloads the shell on initial run | ||
| # TODO: deduplicate already watched file paths? |
There was a problem hiding this comment.
Could easily be done with assosiative arrays but that needs bash 4. Seeing as macos only ships with version 3, that is probably a no go.
I wonder if it would makes sense to move some of this logic to the rust core where you would have much more freedom and power to do what you want. But keeping everything in simple bash has the benefit that the barrier to enter/debug is quite a bit lower.
Proof of concept. Based on ideas from #1180.