Fork me on GitHub
#boot
<
2018-09-30
>
zalky13:09:26

Hi all, quick Q about loading environments. I've often seen them loaded at task construction time, rather than execution time.

(deftask task
  []
  (set-env! ...)
  (comp (task-1) (task-2) ...))
Loading tasks at construction time would appear to make it difficult to compose tasks that require different environments. First impression for a simple boot task that loads an environment inline during task execution might be:
(deftask load-env
  [e env ENV code "Environment map"]
  (with-pre-wrap fileset
    (->> env
         (apply concat)
         (apply set-env!))
    fileset))

(deftask task
  []
  (comp (load-env :env env) (task-1) (task-2) ...))
However, this does not seem to work with some tasks, for instance adding clojure source as resources when packaging as a lib. Is there some reason changing environments during task execution time is not a good idea? Or would you expect this to work.

zalky13:09:07

Maybe load-env is not correct? I've also tried commit! on the fileset after the environment change, but didn't make a difference.

viesti15:09:17

Hum, tried to do a setup where I’d have one parent project and would run subprojects in pods, each with their own :source-paths and :dependencies. Somehow :source-paths aren’t getting into effect until loaded in the parent project env. Wondering what I’m doing wrong here:

0% mkdir project
0% cd project
0% mkdir -p subproject/src
0% echo '(ns hello)\n(println "hello")' > subproject/src/hello.clj
0% cat subproject/src/hello.clj
(ns hello)
(println "hello")
0% boot repl
nREPL server started on port 64568 on host 127.0.0.1 - 
java.lang.Exception: No namespace: reply.eval-modes.nrepl found
REPL-y 0.4.1, nREPL 0.4.4
Clojure 1.8.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_171-b11
        Exit: Control+D or (exit) or (quit)
    Commands: (user/help)
        Docs: (doc function-name-here)
              (find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
      Source: (source function-name-here)
     Javadoc: (javadoc java-object-or-class-here)
    Examples from : [clojuredocs or cdoc]
              (user/clojuredocs name-here)
              (user/clojuredocs "ns-here" "name-here")
boot.user=> (require '[boot.pod :as pod])
nil
boot.user=> (def p (pod/make-pod (assoc (get-env) :source-paths #{"subproject/src"})))
#'boot.user/p
boot.user=> (pod/with-eval-in p (require 'hello))
java.io.FileNotFoundException: Could not locate hello__init.class or hello.clj on classpath.
boot.user=> (set-env! :source-paths #{"subproject/src"})
nil
boot.user=> (def p (pod/make-pod (assoc (get-env) :source-paths #{"subproject/src"})))
#'boot.user/p
boot.user=> (pod/with-eval-in p (require 'hello))
hello
nil
boot.user=>

viesti15:09:29

sorry for the long paste 😬

viesti18:09:51

hmm, so after reading source, thinking that I source-paths behave a little different than dependencies

viesti18:09:38

using directories for source code yields the pod seeing the code, but I’m not sure if this is ok thing to do, compared to calling set-env! :source-paths right before creating a pod: boot.user=> (def p (pod/make-pod (update (get-env) :directories conj "subproject/src")))