This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (133)
- # boot (59)
- # cider (5)
- # cljs-dev (30)
- # cljsrn (23)
- # clojure (212)
- # clojure-austin (3)
- # clojure-brasil (1)
- # clojure-chicago (5)
- # clojure-italy (10)
- # clojure-russia (5)
- # clojure-serbia (1)
- # clojure-spec (34)
- # clojure-turkiye (2)
- # clojure-uk (132)
- # clojurescript (163)
- # clojutre (1)
- # cursive (5)
- # datomic (58)
- # emacs (42)
- # events (1)
- # graphql (26)
- # hoplon (16)
- # jobs (1)
- # lumo (27)
- # numerical-computing (3)
- # off-topic (127)
- # om (9)
- # onyx (24)
- # re-frame (20)
- # reagent (20)
- # ring-swagger (14)
- # sql (19)
- # unrepl (28)
- # untangled (3)
- # vim (8)
- # yada (17)
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)
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 ?
https://github.com/adzerk-oss/boot-reload/issues/68 unfortunately boot-reload doesn't work with nodejs it seems
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?
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.
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.
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
You could replace it with:
and it would just fetch your deps if they were done in a
Completely agree. Only issue is that there are multiple scripts, each with their own
@pjullah Got it. Do you have multiple build.boot files? Or multiple tasks within a single bulild.boot?
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
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.
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?
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
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. 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?
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 https://github.com/weavejester/environ would be part of a correct approach.
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