arm binaries are built for linux, would be nice to have them for mac as well to avoid dependency on rosetta.

see also https://github.com/babashka/pod-babashka-fswatcher/releases/tag/v0.0.4

(pods/load-pod 'org.babashka/fswatcher "0.0.2")
(require '[pod.babashka.fswatcher :as fw])

(def count (atom 0))

(def watcher (fw/watch "some-file.txt"
                       (fn [event]
                         (do
                           (prn event)
                           (swap! count inc)))
                       {:delay-ms 250}))

When I modify the file then it prints twice and increments count from 0 to 2.

@lispyclouds The script in test/script.clj is now a proper runnable babashka test script. It returns a non-zero exit code when the compiled pod doesn't work correctly. Maybe we can hook this up as a test in CI and run it with babashka.

unwatch is something different: you give it some paths and it will stop watching those, while still watching the others

By quickly looking into it, it seems to be an expected behaviour because the watchers are being added to the base directory and to the file itself.

There's dedup logic as an example in fsnotify

Should this test assert that there's only one event? https://github.com/babashka/pod-babashka-fswatcher/blob/main/test/script.clj#L38

Steps to reproduce

I have a single file bb.edn in my dir

{:paths ["src"]
 :pods {org.babashka/fswatcher {:version "0.0.3"}}
 :tasks
 { watch {:requires ([pod.babashka.fswatcher :as fw]
                     [babashka.fs :as fs])
                :task (do (fw/watch "." prn {:recursive true :delay-ms 500})
                          (deref (promise)))}}}

I start my watcher:

[fsousa@work fs-watch-issue]$ bb watch 
{:type :write, :path "./bb.edn"}
{:type :write, :path "bb.edn"}
{:type :write, :path "./bb.edn"}
{:type :write, :path "bb.edn"}

then just modify bb.edn with a new line.

I usually go with EPL-1 since that's what Clojure uses, but since this code doesn't have any Clojure core sources in it, we can choose whatever we want. Up to you @lispyclouds. I added a copyright statement in the README. We will have to add a LICENSE file.

@lispyclouds I figured that name might be more fitting since we base our watcher on this lib?

The latest release is missing an executable for Linux aarch64.

I'm getting this stacktrace from fswatcher:

#error {
 :cause "java.lang.String cannot be cast to clojure.lang.Associative"
 :via
 [{:type java.lang.ClassCastException
   :message "java.lang.String cannot be cast to clojure.lang.Associative"
   :at [clojure.lang.RT assoc "RT.java" 827]}]
 :trace
 [[clojure.lang.RT assoc "RT.java" 827]
  [clojure.core$assoc__5481 invokeStatic "core.clj" 193]
  [clojure.core$update invokeStatic "core.clj" 6231]
  [clojure.core$update invoke "core.clj" 6223]
  [sci.impl.vars.SciVar invoke "vars.cljc" 334]
  [sci.impl.analyzer$return_call$reify__9096 eval "analyzer.cljc" 1180]
  [sci.impl.analyzer$return_binding_call$reify__8967 eval "analyzer.cljc" 1098]
  [sci.impl.fns$fun$arity_1__7412 invoke "fns.cljc" 106]
  [babashka.pods.impl$processor invokeStatic "impl.clj" 227]
  [babashka.pods.sci$load_pod$fn__30772 invoke "sci.clj" 119]
  [sci.impl.vars$binding_conveyor_fn$fn__343 invoke "vars.cljc" 154]
  [clojure.core$binding_conveyor_fn$fn__5823 invoke "core.clj" 2047]
  [clojure.lang.AFn call "AFn.java" 18]
  [java.util.concurrent.FutureTask run "FutureTask.java" 264]
  [java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1128]
  [java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 628]
  [java.lang.Thread run "Thread.java" 829]
  [com.oracle.svm.core.thread.JavaThreads threadStartRoutine "JavaThreads.java" 597]

I think what's going on is that in the error cases, event is a string on this line:

And the call to update with a string argument causes the crash.

It seems like this is because in error cases, babashka.WriteInvokeResponse is being called with a json string rather than a Response struct:

(fs/watch ["src" "test"] ...)

and perhaps deprecate the single path argument