File watch watches unrelated libs

[dten]

I have for example a stack.yaml with two packages in, neither of which reference each other. Let's call them package0 and package1

stack build package0 --file-watch

this results in watching all the files of package0 (good) but also all the lib files of package1 (seems bad).

I can't figure out a reason to watch the .hs files and the .md files of the other package. my logic for watching the cabal file also seems a bit weak.

Is this intended behaviour? Am I missing some reasoning where package1 could affect package0 if package0's dependency graph doesn't mention it?

and just in case it's just me i'm on ubuntu 18 under wsl (windows 10 1909) with stack 2.1.3

❯ stack --version
Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2

[qrilka]

@dten could you provide an example project reproducing this?

[dten]

Sure, here's stack new testlibs copy pasted and renamed

testlibs.zip (edit: this one slightly wrong)

stack build testlibs:lib --file-watch and then watched shows

watched
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/stack.yaml
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs/ChangeLog.md
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs/README.md
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs/package.yaml
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs/src/Lib.hs
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs/testlibs.cabal
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs2/ChangeLog.md
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs2/README.md
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs2/package.yaml
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs2/src/Lib.hs
/mnt/c/Users/DavidHewson/Documents/Repositories/testlibs/testlibs2/testlibs2.cabal

edit: hmm i actually made testlib2's executable depend on testlib, so it's not quite what i said

[dten]

testlibs.zip

fixed not renaming enough in testlibs2. now truly unrelated

[qrilka]

Thanks, hopefully I will find some time to look into it soon.

[qrilka]

@dten it looks like currently all local files get tracked not only project package files but also local deps as well see https://github.com/commercialhaskell/stack/blob/master/src/Stack/Build.hs#L67

So it appears that what you want is not the way Stack currently works but changing that seems to be doable and I don't see any arguments against this. @snoyberg what do you think if --file-watch will respect build targets?

[snoyberg]

Seems reasonable to me, no objections

[qrilka]

@snoyberg the fix is quite easy but I'm not sure what do we do with backwards-compatibility. The least surprising would be to add an extra explicit flag, something like --granular-watch without which file watching will work as before. At the same time this makes interface of granular watching somewhat ugly, it would be better to use stack build some-lib --file-watch instead of stack build some-lib --file-watch --granular-watch.
What would you prefer here?

[snoyberg]

I think we can just make the change, perhaps with a --watch-all flag as well to get back current behavior.

[qrilka]

Thanks, I like this variant