Filter dependencies on pods

Sometimes boot tasks have conflicts with your project. You can filter the dependencies that will be used on the pod using this: Source: Micha Niskin on Slack

(defmacro with-env
  [env & body]
  (let [orig (into {} (map #(vector % (gensym)) (keys env)))]
    `(let [~@(mapcat (fn [[k v]] [v `(get-env ~k)]) orig)]
       ~@(for [[k v] env] `(set-env! ~k ~v))
       (with-let [ret# (do ~@body)]
         ~@(for [[k v] orig] `(set-env! ~k ~v))))))

(defn filter-deps
  [deps]
  (->> (get-env :dependencies)
       (filterv #(some (set deps) ((juxt first (comp symbol name first)) %)))))

(defmacro with-deps
  [deps & body]
  `(with-env {:dependencies (filter-deps '~deps)} ~@body))

Usage: Project has deps that conflict with boot-jetty, so we filter all of those out when we instantiate the task--it will not create pods with the troublesome deps.

(deftask foo
  []
  (comp (watch)
        (hoplon)
        (cljs)
        (with-deps [boot-jetty] (serve))))

Why env should be customizeable on a per-pod/per-task basis

This is a discussion and not part of the documentation.

• Separate dependencies (other env parameters?) of frontend & backend

  • [DM] Just had a bug that would have been avoided if I had this. One of my backend dependencies depended on a guava version incompatible with clojurescript.
  • [MS] You don't always want the same version of a dependency on the frontend and backend on a project.

• [AR] Define dependencies (other env parameters?) at task creation time

  • Example: in order to supply deps to boot-cljs's pod at the moment you need to call set-env! which is bad as it overrides the current boot.user env. This side effect should be avoided.

Possible solutions

• Implement dynamic var env that is used by get-env
• Have an --env option that equally specifies what will be returned by get-env
• ...