when compile-clj fails, it should leave the temp directory there for debugging

does that file exist? if so, can you read it?

That directory "uber..." does not exist.

oops one sec.

yeah that directory does not exist.

no directories starting with that name exist.

I switched to :use-cp-file :always

Sorry 🌄 ":never"

oh sorry, that's the uber building dir, my previous comment was re compile-clj so is not relevant

you mentioned modifying the options of compile-clj, but you should be modifying the options of uber to affect behavior

ahhh

ok tried that with same result:

(defn uber [_]
  (b/copy-dir {:src-dirs ["src"]
               :target-dir class-dir})
  (b/compile-clj {:basis basis
                  :use-cp-file :never
                  :src-dirs ["src"]
                  :class-dir class-dir})
  (b/uber {:class-dir class-dir
           :uber-file uber-file
           :exclude [#"(?i)^META-INF/LICENSE/.*"
                     #"^LICENSE/.*"]
           :basis basis
           ...

I solved the issue by adding ".*LICENSE.*" to :exclude in above.

Thanks @U04V15CAJ.

This may be caused by Windows \\ instead of / Perhaps tools build can normalize/unixify the paths before comparing or so

@U0FH1UL84 So it worked with :use-cp-file :never?

yeah

ah ok then

The space in my user name (home dir) was probably an issue.

Not sure why it worked since I was likely over the 8k character limit.

spaces in paths should be handled imo

could be a problem with scoop clojure via bash.

bash?

windows git bash

ok, maybe also try in cmd.exe and pwsh.exe then

ok will try

No, problem exists in powershell too.

Can you re-define what "the problem" is since that information is in #clj-on-windows in a thread over there, which was a different problem than the original post of this one

Or start a new thread over here about that one

Sure I'll post here again to make it clear.

I suspect there are quite a few tools out there that will fail on directory paths that contain spaces. I've seen a lot of people recommend to have user names without spaces on Windows because of that (`Program Files` can also be problematic if folks install non-native-Windows tooling there).

I'm using the clojure installed by scoop on windows.

Let's use a thread for multiple messages about the same problem

Maybe the main (that with :gen-class) namespace isn't currently requireing the ns that shows this behavior? Although I'm using :src-dirs so it should compile everything

do you have a user.clj?

no

have you looked in the output jar to see if the namespace you want to be compiled without assertions is present in the output?

off-hand, don't know. you can fork tools.build, add any print debugging you need, and point to the fork via either :local/root or to a commit sha in your fork, if that helps

the aot classes for the namespace are not present in the output, then when you load the code later it will be compiled then with whatever flags that are set then

I'm always surprised when I see folks turning assert off in production... Don't you want your app to "fail fast" rather than potentially continue on with bad data and cause havoc? I've always preferred to keep assert ON in production for that reason...

I've shared this link a few times over the years :) https://en.wikipedia.org/wiki/Design_by_contract#Performance_implications The liberating thing about disabling it is that you can go as creative and heavy-handed as desired with assertions, without worrying about performance. It also helps drawing a clear line between assertionerror and ex-info (things that aren't dev sanity checks should be the latter). Particularly when assertionerror does not inherit from Exception

Back to the topic, the expected .classis there and (print *assert*) during compile-time printed false, as expected Will investigate some other day

And how do you know asserts are being triggered(

Gotta go put kids to bed, but wild guess you are seeing spec asserts fail, and if I recall spec asserts don't respect assert

correct, they have their own assertion flags

> And how do you know asserts are being triggered a vanilla assert was. for completeness, I ended up using the same solution I've used in past production deployments. It should be redundant given the build.clj, but this double setup leaves me more assured.

(ns my.app.launcher
  "Please don't add any requires here."
  (:gen-class))

(defn -main [& args]
  (binding [*assert* false] ;; Bind *assert* before performing any requires
    (let [f @(requiring-resolve ')]
      (apply f args))))