Clojurians Log v2

util-clean-shadow-cache     {:task (shell (str "rm -rf ./.shadow-cljs/builds"))}

@rdonahue You can use babashka.fs instead of you want to make it less OS-specific.

(babashka.fs/delete-tree ".shadow-cljs/builds")

That sounds like a wonderful idea

Ooh it definitely changed the error 🙂

Type:     java.nio.file.DirectoryNotEmptyException
Message:  .shadow-cljs/builds/pnx/dev
Location: <expr>:26:1

delete-tree should remove a directory recursively

but perhaps there are files you don't have permission to delete?

Maybe files that are in use by the shadow-cljs watch process?

maybe my mac is trying to “help”

it could also be that files are being recreating during delete

or something with symlinks

you could try one more thing.

Deletes a file tree using walk-file-tree. Similar to rm -rf. Does not follow symlinks. force ensures read-only directories/files are deleted. Similar to chmod -R +wx + rm -rf

(fs/delete-tree "...." {:force true})

this will take care of file permissions being set right so you can delete

I do love applying force to deletes

its only bitten me.. like 3% of the time 😉

Ok, combining force with being more specific in the delete (.shadow-cljs/builds/{app}/release) seems to be doing the trick

Thanks for the suggestions and you know, babashka, which is lovely.

thanks :)

> Maybe files that are in use by the shadow-cljs watch process? On Unix systems files can be deleted while in use, and they are removed from the directory tree immediately, so that shouldn't be the issue. (They are kept as "detached" inodes in the file descriptors table, and the actual drive space is not freed, until they are properly closed.) As Michiel said, it's either files you didn't have permission to remove (but then you should have error messages about that somewhere), or files that are being created while you delete - rm -rf still has to walk down the tree one file at a time, so it is possible, if you have another concurrent process using that directory, that it "misses" the new files, and then when it moves back up to the directory level, the directory is not empty even though it's deleted all the files it knew about when it started.

ah, I guess it's because I have a :deps in my bb.edn, so it's expected. Shame we can't package java directly in the bin 🙃

It only does this for fetching dependencies via tools.deps if you have any specified in bb.edn

technically there is a way to do this without java. https://github.com/babashka/pod-registry/blob/master/examples/tools-deps-native.clj

hmm sorry for the noob question but does bb.edn have something similar to the deps.edn approach for having deps per alias? The singular dep I have here is only for a task I use in development, and I'm using the static binary for running in "prod" (ahem, a lima vm atm)

you can have :extra-deps per task

thank you! I got it working! :D

(what I was working on: https://github.com/socksy/bb-tower-deploy/)

cool! just a small side-note: > which is a graalvm image so presumably has the entire JVM inside of it this isn't true, the smallest GraalVM image is only 5mb or so. The virtual machine that goes along with it is called Substrate VM - not a full JVM. But it is true that the bb binary isn't small, this is mostly due to the included libraries and Java classes. it's around 70-80mb in most cases. zipped 20mb or so.