Is there an idiomatic way to use pods? How many/few should I use? I’m writing an internal tool (equivalent to a lein plugin) with boot tasks, with 2 unrelated namespaces that have different deps/etc. Should each use a pod? Should the tool share a pod? Does it matter?

@andrewmcveigh: Yes, they should use pods. Doesn't matter much is they use separate or shared pod. If one odesn't depend on another, should be possible and good idea to use separate pods.

@juhoteperi: Thanks, I have them in 2 separate pods atm. They don’t depend on each other, but one task might need to call into both.

I guess I should just use whatever is simpler.

So now that 1.7 is official, is there any good resource/project that shows how migrate from cljx to cljc? Possibly with boot?

I’m not sure boot is the cause, but I’ll ask here anyway 😛 I’m working on an app that uses the ptaoussanis/sente and everything works fine until I add core.match as a dependency. I don’t even need to use require it in any namespace. Just add the dependency.

@samflores: my guess is a dependency problem related to tools.analyzer, which is brought in by core.match directly and sente indirectly (through core.async)

@samflores: you could start with boot -d com.taoensso/sente:1.5.0 -d org.clojure/core.match:0.3.0-alpha4 show -p to see the selections maven is making for you, and pick some tactical exclusions

@samflores: this appears to compute: (set-env! :dependencies '[[org.clojure/core.match "0.3.0-alpha4" :exclusions [org.clojure/tools.analyzer.jvm]] [com.taoensso/sente "1.5.0"]])

That was really a great tip. I’ve tried running boot show -p in my project directory and got the same error. Didn’t remember I could run boot without a build.boot and give it the parameters. 😄

Thank you!

(inc :alandipert)

haha no prob

Okay. Howdoi boot to the head.

From the context of a task, can I modify other tasks options? I'm trying to build a test task which alters the pom task's version using a version parsed from the git tag. (task-options! pom {:version version}) doesn't seem to be doing it... there's magic in the pom symbol that I haven't figured out yet.

boot doesn't have a big map of configuration like that

https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/core.clj#L799

tasks aren't really designed to be coupled like that

you're altering var meta

correct

yuck

okay

def is for side effects

we don't have an immutable map as a namespace in clojure

because we'd lose all the dynamic benefits if we did

task-options! is like def

but what are you wanting to do?

there is maybe a more direct way

nothing should be magical hopefully

I have four tightly coupled lein projects that are version controlled together. At present we use https://github.com/cvillecsteele/lein-git-version to coordinate versions across the subprojects. In evaluating boot I figured it'd be a good exercise to port that sort of task to boot.

can you paste what you have?

(ns factual.boot-git-version
  {:boot/export-tasks true}
  (:refer-clojure :exclude [test])
  (:require [boot.pod  :as pod]
            [boot.core :as core]
            [ :as io]
            [clojure.java.shell :refer [sh]]))

(defn get-git-version
  []
  (->> (sh "git" "describe" "--match" "v*.*" "--abbrev=4" "--dirty=**DIRTY**")
       :out
       clojure.string/trim
       rest
       (apply str)))

(defn get-git-ref
  []
  (->> (sh "git" "rev-parse" "--verify" "HEAD")
       :out
       clojure.string/trim
       rest
       (apply str)))

(core/deftask git-version
  [v  version-file      bool   "Create a version statement file."
   p  version-ns-prefix string "Namespace where the version defs will be written"]
  (let [version (get-git-version)
        ref     (get-git-ref)]

    ;; If appropriate, build and install a version file
    (when version-file
      (let [temp-dir  (core/tmp-dir!)
            pname     (name (get (core/get-env core/pom) :project))
            temp-file (io/file temp-dir pname "version.clj")]

        ;; Write the file
        (spit temp-file
              (format
               (str ";; Do not edit. Generated by factual/boot-git-version.\n"
                    "(ns %s)\n"
                    "(def version \"%s\")\n"
                    "(def gitref \"%s\")\n")
               ns version ref))

        ;; Add it to the fileset
        (core/with-pre-wrap fileset
          (-> fileset
              (core/add-source temp-dir)
              (core/commit!)))))

    ;; Set the POM version
    (task-options! core/pom {:version version})))

fairly direct port except for the actually doing anything to the fileset bit 😛

hm

the task should return the middleware

you might want to move the call to task-options! up to the top there

the "env" btw is not like the lein project map

the env is how the JVM environment is configured

it's part of the bootstrapping process

it contains configuration for boot's lower level bootstrapping

like maven deps, things like that

options for aether and for its own worker thread setups

tasks like the pom task are configured by currying their arguments

Gotcha. So those pom options are things I'm gonna have to dig off of the pom task.

or pass it to both, probably

i mean your task could set the pom task option

or I could just partially apply pom and return that, no?

you'd want to compose it then

like

(comp
  (with-pre-wrap ...)
  (pom ...))

or something

it's like ring middleware

(def wrap-foo [handler]
  (wrap-bar handler)
  (wrap-baz handler))

the wrap-bar middleware wouldn't be doing anything there

basically your task should return middleware that can be composed by the user into a pipeline

boot watch git-version aot -n my.namespace jar -m my.namespace

or something

Okay.

another thng you can do is if a task almost does what you want, but for some reason isn't compatible, you can just use the underlying functions that task uses

in your own task

like if the pom task is problematic, you can probably use the functions it's using

inside your own pom task

Okay.

one thing you can also do that will make it pom task agnostic:

instead of having your task compute the path to the version.clj file, you can use file extensions for this

make a file in the source that is like my/namespace/version.clj.foo

and have your task just extract that from the fileset

maybe version.clj.edn, which would be an edn template

then in your task do (->> fileset core/input-files (core/by-name ["version.clj.edn"])) to get the file

you can then write to it

this would be the idiomatic boot way

it could take that file and know the path to the generated file (i.e. remove the .edn extension or whatever)

and it would be completely decoupled from the pom configuration

the main difference between boot and lein is that in boot tasks cooperate via the fileset

and in lein they cooperate via the project map

fishing around in the pom task configuration options is like the project map pattern kinda