Fork me on GitHub

Just to double-check: boot push --repo clojars doesn’t require any GPG stuff these days, right? They disabled all that signing and promotion stuff, and you can just enter your clojars credentials when prompted, or put them in your ~/.boot/profile.boot as plain text if you want, right?


(based on the Clojars wiki and the Boot wiki, that definitely seems to be the case)


@seancorfield I think that’s correct yes


Hey. So I've been playing with ClojureScript on Node these past weeks. I ended up hacking some code together in my boot file to call "nodemon" (to reload the node app on changes) and letting boot-cljs handle compilation. It.. works.. but I was referred to this ( ) by a colleague and after playing with it yesterday, I must say it has some benefits (namely that I get better reloading support). Anyone got ideas on how to make the Node.js development experience under boot be a little nicer ?


boot-figreload is much newer. So may be unstable.

dominicm10:06:38 unfortunately boot-reload doesn't work with nodejs it seems


Hey. I've just wasted another hour and a half debugging WTH boot could not parse my string argument. Long story short, turned out that my arg definition:

[i input S3PATH str "blablabla"]
creates a parse function that turns the provided string into a vector, and then the verifier fails. Turns out the 3 in S3PATH was to blame. Nowhere in the documentation I could find any mention that digits in the optarg name change the parser behavior. I'm too frustrated and annoyed right now to document this via PR. Just leaving it here.


alexyakushev: I agree, I often find it hard to understand the arg parsing in boot.


@U06PNK4HG to trigger that issue, did you run boot from the CLI or REPL?


I can reproduce some weirdness in this area but I’m not sure I understand how you figured out that it’s turned into a vector


@U050TNB9F: This is a Boot script:

;; I use this alter-var-root to debug-print the value that is parsed.
(alter-var-root #'boot.cli/assert-type
                (fn [old-fn]
                  (fn [type val]
                    (println "Value" val "should be of type" type)
                    (old-fn type val))))

(boot.cli/defclifn -main
  [p path S3PATH str "a path"]
  (println "The path is" path))
Here is the shell output:
$ boot -f test.clj -- -p '/foo/bar'
Value [/foo/bar nil] should be of type str
                                                  Boot.main                258
                                              boot.App.main                 491
                                           boot.App.runBoot                 399
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke 150
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke 159
                                            boot.main/-main                          main.clj: 206
                                         boot.main/-main/fn                          main.clj: 206
                                          boot.user/eval135  boot.user6583161146594871082.clj:  25
                                       boot.user/eval115/fn  boot.user6583161146594871082.clj:  21
java.lang.IllegalArgumentException: option :path must be of type str
        clojure.lang.ExceptionInfo: option :path must be of type str
    file: "/var/folders/jq/j47skpq56p56rwvhn_08fk0c0000gp/T/boot.user6583161146594871082.clj"
    line: 25


thanks, that’s useful!


No problem. I think the behavior to blame is here: Perhaps it is intended, but then it is underdocumented.


Yeah seems like it here too…


Or in general why the (remove A-Z? …) exists?


i don’t, no


@dominicm hey - thanks 🙂 I'll try that out for sure 🙂


Hey. I’m looking for some help/advice with a Boot and Docker. Docker is incidental really, the problem I’m facing more concerns dependencies. As background, what I’m trying to accomplish is: build a docker image containing some Boot scripts which perform admin tasks against a DB. For this, I’m using the adzerk/boot-clj image, but my experience so far is that dependencies are fetched each time I run a new container. However, I was hoping that there would be some way to bake the dependencies into the image. So I guess I have two questions: 1. Am I using the adzerk image incorrectly (I can’t say I fully understand this line - /usr/bin/boot web -s doesnt/exist repl -e '(System/exit 0)' && rm -rf target) 2. Is there a way to pull the .jar files using Maven independently of Boot? Thanks


One thing that I have tried that works quite well is mount ~/.m2 (host) onto /m2 (container) - but I'd rather not rely on this.


@pjullah The trick to it is probably to extend adzerk/boot-clj as a base image. ADD your files. Then RUN /usr/bin/boot which will fetch the deps


@dominicm Thanks. Adding the files is the step I'm stuck with I guess. I can manually fetch the jar files, it's knowing how to structure them inside the image. I'm stretching the limits of my Java knowledge here (which isn't much) but .. there is a Maven repo (/m2) inside the image that Boot knows about. But I presume, from looking at ~/.m2 on my machine that there is a specific structure required, so I can't just dump the files. I was hoping there would be a file (pom?) that I could construct and pass to Maven to fetch jars and then build a valid directory structure under /m2. That was my hope anyway.


You don't need to manually fetch them. Don't worry. You can have boot do it.


OK. I see your point.


Are you working from the example in the repo @pjullah ?


Although... There are several Boot scripts that I am ADD'ing to the image. I would have to run boot script1 then boot script2 etc inside a running container, because each script will have different deps. I would then need to commit the changes to to the container to create another image. I could do it this way.


Yes, following instructions from the link


You are, sorry. I've gone full circle now 😆. RUN /usr/bin/boot web -s doesnt/exist repl -e '(System/exit 0)' && rm -rf target ^^ this line is supposed to be the build: - Fetch the deps - compile any cljs if appropraite - etc. You could replace it with: RUN /usr/bin/boot and it would just fetch your deps if they were done in a set-env!


Completely agree. Only issue is that there are multiple scripts, each with their own set-env!


perhaps multiple RUN commands


@pjullah Got it. Do you have multiple build.boot files? Or multiple tasks within a single bulild.boot?


Multiple build.boot files.


Either way, I'd advise condensing the RUN into a single command due to caching in Docker:

RUN cd dir1 \
&& /usr/bin/boot \
&& cd dir2 \
&& /usr/bin/boot


Using multiple tasks would be a nice alternative thought.


I think this is the accepted way of doing it ^^


🙂 thanks.


Actually, thinking on it a little more, of the two options I think I prefer a single build.boot with multiple tasks. That way my image could have a single ENTRYPOINT which would make the docker run cleaner.


Thanks for your help/advice.


@dominicm BTW - it works really nicely.


@pjullah That's great to hear! I'm glad


hey folks- been running into inotify limit on CircleCi a la, and I see there’s a mitigating feature on master, but that’s not included in any release yet afaict. is it realistic/stable to build boot from master myself for use by CircleCi and/or is there a Better Way?


@calvis building boot from master is good, but there’s another, potentially easier workaround also - build and use this thing


i think we’ll probably release another versino in a month or two so you won’t have to hack around it for much longer


alright thanks


@alandipert stubwatch is a great workaround


@pesterhazy thanks, i never personally confirmed it worked on circleci tho


random idea: we could setup travis to publish jars for master (+ other branches) which would make it much easier for people to get feedback on their feature branches etc.


Regarding the #= reader macro. I am working on getting boot to work with visual studio code. see: 3. Add the Debug Middleware to Your Project The issue is with the #=() reader macro. The goal is to place an environment parameter in a (set-env! ...) value. What is the recommended way to do this with boot?


@phreed set-env! is a function, so i think you can do something like (set-env! :dependencies [[(System/getenv "ARTIFACT_NAME") "1.0.0"]]) perhaps?


another option is (set-env! :dependencies (template [[foo/bar "1.0.0"] [~(System/getenv "FOO") "2.0.0"]])) - template is a function in boot.core that works like syntax quote, but doesn’t qualify symbols


@alandipert That seems right. I am puzzled as to what situation would necessitate the #=() reader macro. It seems like the environ package would be part of a correct approach.


it’s necessary when there isn’t normal evaluation, such as in macros


ie inside ns


or defproject in a project.clj


since boot is oriented around normal evaluation, and there are functions for getting environment variables and system properties, i’ve never felt the need for anything like environ, personally


I see, that makes sense.