Excellent, I can now deprecate carve? :)

hahah I expect carve to have a better configurability ATM, but it's easy to improve on clojure-lsp 🙂 carve seems a valid another approach not using the LSP protocol so having both options sounds good for community 😄

Also, not sure all features carve provide, if all of them are alreday included in the clean-ns refactoring

Does clojure-lsp also offer a REPL API?

Yes @U04V15CAJ with that release, the clojure-lsp.api should provide those features 🙂 https://clojure-lsp.github.io/clojure-lsp/api/

This is quite cool! For some reason I need to do this clojure-lsp -p ./ clean-ns to manage the clean-ns work in my repos, is that intended?

the default of the -p flag is the current dir, what error you were getting @UMMMKKADU?

no errors, is just not doing anything

I use zsh btw

it's correct, it have no namespaces to clean 😅 Maybe a Cleaned! print is missing 🙂

hahaa

it will print the namespace cleaned only if it needs to clean anything

you can confirm that, adding a unused var or sorting differently

yeah it only shows up when I use -p

instead it just prints 0ms

but this is such a good tool, thanks a lot https://github.com/parenthesin/microservice-boilerplate/pull/13/files

haha

Thanks! will investigate further more soon your project issue

Perhaps it's related to not having an .lsp/config.edn ?

I do have only an ~/.lsp/config.edn and just the ./clj-kondo/config.edn at projects level

yes, I meant the project level

could be related, dunno. I think it should be optional

I don't think so, it probably some issue with the -p default value, in this case (io/file (System/getProperty "user.dir"))

I copied my personal .lsp/config.edn at project level and still having the same behaviour

yeah, it's not related with the config

Want me to open a issue?

Sure!

https://github.com/clojure-lsp/clojure-lsp/issues/463

@UKFSJSM38 Sorry to interrupt your release Eric, but I don't think your recent commits fixed anything :)

The problem is that you are capturing values at build time

(System/getProperty "user.dir") should work, but not when you put it in a top level def

This is because static initializers are initialized at build time in graalvm native image with the --initialize-at-build-time option

Hum, it makes sense, but I tested with the @UMMMKKADU project, let me double check

Perhaps your commit fixed something because the path is relative now, but this is the real reason it was broken

I guess the commits do work, but I was surprised you were still using top level defs, which is probably not a good idea

you are right, it's missing running it in a function, or using default-fn instead of default

I mean for storing values that can be different over systems

yeah, it's probably a good idea I change that cli-options to be a function

The CLI options are alright, but the defaults should just be handled dynamically, probably not using tools.cli itself

just using or in the main function or so

why it's a problem handling in tools.cli if that cli-options would be a function?

that works too

alright, I'll improve that to be a function, thanks for the heads up 🙂

a delay works too

yes, but I think changing

:default (io/file "")

:default-fn #(io/file "")

what is best, change to that ☝️ or change cli-optiosn to be a function?

oh I didn't know you vould provide a function for :default-fn, yeah that works too

yeah, that looks better 🙂 I just need to remember for every new option

maybe make a note ;)

Released the fix!

A full walk-through is available in https://github.com/sauercrowd/clojureflare/tree/main/example-worker