You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it make sense to allow the Haskell expression passed in with the --test option to somehow declare what non-Haskell files it ended up depending on, so that they can be added to the watch list.
This would allow a tighter integration with any workflow that involves external files. Application configurations, test inputs/outputs or, in my case, DB migrations would be useful to watch this way.
I guess one can also organize the project file structure so that all interesting files live under predetermined folders so one can pass those folders to --reload, but being able to declare these dynamically might allow richer workflows.
Another alternative could be to use a --test expression that keeps running after doing what it's supposed to do and then it starts watching the files itself and repeats what it does when any of them change. This avoids the need for any cooperation from ghcid, but I think this is a clunkier solution.
As for how this ticket might work; Would it be possible to let the --test expression to produce a result of some special type that ghcid interprets specially. Maybe a record that contains a field externalDependencies :: [FilePath]. Or maybe ghcid just shows the output of the expression as usual and just interprets the string looking for some special forms, similar to how --allow-eval looks for -- $> comments to evaluate.
The text was updated successfully, but these errors were encountered:
I think having test figure out new dependencies would be possible, but I wonder if the ability to do so dynamically is worth the hassle? Are the things being read hard to figure out in advance (or at least an approximation thereof) and put in --reload? I'm not sure this feature would be that heavily used.
I agree, it would be unusual to have use cases that can't be addressed with --reload. In my case, I'm trying to set up an unusual workflow involving a Haskell eDSL and some external files and the audience for this workflow isn't Haskell experts. I think it makes conceptual sense for --test to declare dependencies, since the result of the expression is allowed to depend on arbitrary files.
That said, unless this would be useful to others, I think I can also just start a thread and watch these files myself and touch a file watched by ghcid whenever any of these external files change, triggering a reload.
Would it make sense to allow the Haskell expression passed in with the
--test
option to somehow declare what non-Haskell files it ended up depending on, so that they can be added to the watch list.This would allow a tighter integration with any workflow that involves external files. Application configurations, test inputs/outputs or, in my case, DB migrations would be useful to watch this way.
I guess one can also organize the project file structure so that all interesting files live under predetermined folders so one can pass those folders to
--reload
, but being able to declare these dynamically might allow richer workflows.Another alternative could be to use a
--test
expression that keeps running after doing what it's supposed to do and then it starts watching the files itself and repeats what it does when any of them change. This avoids the need for any cooperation fromghcid
, but I think this is a clunkier solution.As for how this ticket might work; Would it be possible to let the
--test
expression to produce a result of some special type thatghcid
interprets specially. Maybe a record that contains a fieldexternalDependencies :: [FilePath]
. Or maybeghcid
justshow
s the output of the expression as usual and just interprets the string looking for some special forms, similar to how--allow-eval
looks for-- $>
comments to evaluate.The text was updated successfully, but these errors were encountered: