Missing Linux aarch64 release about pod-babashka-fswatcher HOT 6 CLOSED

cc @lispyclouds - is it possible to cross compile the go library to linux aarch64?

from pod-babashka-fswatcher.

I was able to compile the pod on arm64 myself in go, and I believe cross-compiling should be as simple as setting GOARCH=arm64 at compile time.

I was able to get babashka to use the pod I compiled by putting it in the appropriate ~/.babashka/pods/repository/ directory and editing the manifest.edn by hand. That get's things working.

Though that was my second attempt. At first I thought that I could just add a :pods {org.babashka/fswatcher {:path "my/custom/pod"} to the bb.edn file and get babaskha to load from disk rather than go and grab it from online, but it seems as though that doesn't prevent load-pod from still trying to grab the pod from the releases here.

I realize this is out of scope of the original complaint, but while I have you, is there a better way to locally override a pod without having to go and edit some library code to excise the load-pod call?

from pod-babashka-fswatcher.

@alexalemi thanks a lot for raising this, we will add in the release soon! As for loading the locally built pod how are you trying to load the pod? with the name and version? then it would still try to get the registry one. If you have declared the :path in bb.edn, it shouldnt need a load-pod call at all. If you need to use the call when developing try it as (load-pod "path/to/the/pod"). Does that help?

from pod-babashka-fswatcher.

Released as 0.0.4.

from pod-babashka-fswatcher.

Thanks for pushing the update!

@alexalemi thanks a lot for raising this, we will add in the release soon! As for loading the locally built pod how are you trying to load the pod? with the name and version? then it would still try to get the registry one. If you have declared the :path in bb.edn, it shouldnt need a load-pod call at all. If you need to use the call when developing try it as (load-pod "path/to/the/pod"). Does that help?

Yeah, that should work, unfortunately, in my case, it was some downstream library (quickblog) that was doing the load-pod call. I was hoping there would be a mechanism to essentially convince the library code that the pod was already cached but refer to a custom pod location. I suppose originally I thought that providing a :pods {org.babashka/fswatcher {:path "my/path"}} in the bb.edn would have prevented the library from attempting to fetch the missing pod.

from pod-babashka-fswatcher.

Feel free to make a PR in quickblog to update the watcher

from pod-babashka-fswatcher.