Fork me on GitHub
#boot
<
2017-06-01
>
seancorfield03:06:01

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?

seancorfield04:06:10

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

martinklepsch04:06:56

@seancorfield I think that’s correct yes

pseud07:06:44

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 (https://github.com/bhauman/lein-figwheel/wiki/Node.js-development-with-figwheel ) 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 ?

dominicm10:06:59

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

dominicm10:06:38

https://github.com/adzerk-oss/boot-reload/issues/68 unfortunately boot-reload doesn't work with nodejs it seems

alexyakushev10:06:31

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.

alexyakushev10:06:31

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.

dominicm10:06:23

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

martinklepsch13:06:02

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

martinklepsch13:06:23

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

alexyakushev13:06:33

@: 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                         Boot.java: 258
                                                        ...
                                              boot.App.main                          App.java: 491
                                           boot.App.runBoot                          App.java: 399
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke       ClojureRuntimeShimImpl.java: 150
org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke       ClojureRuntimeShimImpl.java: 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

martinklepsch14:06:19

thanks, that’s useful!

alexyakushev14:06:36

No problem. I think the behavior to blame is here: https://github.com/boot-clj/boot/blob/ac835cea8c18e926bb843e01579b86e3f30458d2/boot/core/src/boot/cli.clj#L48 Perhaps it is intended, but then it is underdocumented.

martinklepsch14:06:07

Yeah seems like it here too…

martinklepsch14:06:34

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

alandipert14:06:09

i don’t, no

pseud10:06:11

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

pjullah12:06:36

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

pjullah12:06:50

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.

dominicm12:06:22

@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

pjullah13:06:17

@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.

dominicm13:06:44

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

pjullah13:06:03

OK. I see your point.

dominicm13:06:02

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

pjullah13:06:46

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.

pjullah13:06:14

Yes, following instructions from the link

dominicm13:06:28

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!

pjullah13:06:35

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

pjullah13:06:57

perhaps multiple RUN commands

dominicm13:06:09

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

pjullah13:06:26

Multiple build.boot files.

dominicm13:06:54

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

pjullah13:06:58

Using multiple tasks would be a nice alternative thought.

dominicm13:06:02

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

pjullah13:06:09

🙂 thanks.

pjullah13:06:30

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.

pjullah13:06:50

Thanks for your help/advice.

pjullah13:06:15

@dominicm BTW - it works really nicely.

dominicm13:06:29

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

calvis13:06:41

hey folks- been running into inotify limit on CircleCi a la https://github.com/boot-clj/boot/issues/530, and I see there’s a mitigating feature on master https://github.com/boot-clj/boot/pull/564, 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?

alandipert14:06:13

@calvis building boot from master is good, but there’s another, potentially easier workaround also - build and use this thing https://github.com/alandipert/stubwatch

alandipert14:06:36

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

calvis14:06:47

alright thanks

pesterhazy16:06:39

@alandipert stubwatch is a great workaround

alandipert16:06:21

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

martinklepsch17:06:07

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.

phreed19:06:42

Regarding the #= reader macro. I am working on getting boot to work with visual studio code. https://marketplace.visualstudio.com/items?itemName=jamesnorton.continuum 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?

alandipert20:06:31

@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?

alandipert20:06:40

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

phreed20:06:50

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

alandipert20:06:24

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

alandipert20:06:51

ie inside ns

alandipert20:06:56

or defproject in a project.clj

alandipert20:06:24

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

phreed20:06:52

I see, that makes sense.