juxt

p-himik 2021-03-02T14:05:57.010800Z

Hey. I see that https://github.com/juxt/kick.alpha doesn't have the Issues panel enabled, so this is probably the second best place. I noticed that the way the one shot build works doesn't define the order in which the tasks are run. It might cause problems when tasks depend on each other. For example, I'm using Kick to build CLJS but that build also requires some JS files generated by ANTLR4. Obviously, the ANTLR4 step has to be run before the CLJS build step. Do you think it would be reasonable to add dependencies between Kick tasks?

dominicm 2021-03-05T08:11:01.013300Z

You're seeing the limitations of kick, it's really not a good tool, just a convenient one :). I'm hoping that tools.build will absolve me of responsibility.

👍 1
p-himik 2021-03-02T15:20:06.011Z

Another thing - what if you need two steps that use the same provider? And it can be tied to the initial issues - what if there has to be some extra step between the two steps that use the same provider?

p-himik 2021-03-02T17:49:09.012700Z

An unrelated bug: the figwheel-main provider in Kick doesn't work when you have clojure.libfile system property set. This is the relevant code from the provider:

(def kick-paths
  (some-> (or (some->> (System/getProperty "clojure.libfile")
                       (format "{:libs %s}"))
              (System/getProperty "clojure.basis"))
          slurp
          edn/read-string
          :libs
          (get 'juxt/kick.alpha)
          :paths
          set))
Notice how the string that was created by the call for format ends up being passed to slurp, so it tries to read a file named "{:libs ...}".

dominicm 2021-03-05T08:10:10.013100Z

humph, yes. I thought I'd done that right, but clearly not.