Fork me on GitHub
#juxt
<
2021-03-02
>
p-himik14:03:57

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?

p-himik15:03:06

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?

dominicm08:03:01

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.

👍 3
p-himik17:03:09

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 ...}".

dominicm08:03:10

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