This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (13)
- # announcements (1)
- # aws (17)
- # beginners (1)
- # boot (113)
- # cider (71)
- # cljs-dev (7)
- # clojure (93)
- # clojure-android (2)
- # clojure-berlin (1)
- # clojure-dev (22)
- # clojure-italy (3)
- # clojure-japan (1)
- # clojure-poland (41)
- # clojure-russia (96)
- # clojurescript (140)
- # cursive (11)
- # datomic (27)
- # devcards (1)
- # devops (1)
- # events (4)
- # funcool (3)
- # hoplon (133)
- # immutant (7)
- # ldnclj (22)
- # leiningen (5)
- # off-topic (6)
- # om (22)
- # onyx (12)
- # re-frame (8)
- # reagent (12)
@juhoteperi: I know, was just wondering if there's any reason this particular task hasn't been implemented in boot
Project initialization just isn't a feature which would benefit from filesets and other things that Boot provides
Is there a way to parallelize tasks? I have a couple orthogonal concerns in my build pipeline that could benefit from running in parallel.
@jgdavey: we do this in boot-cljs, for example: https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L218
@jgdavey: you can write some coordination logic using futures just like they do, there
there isn’t any general approach in parallelizing tasks but from previous discussions it seems possible
@pandeiro: true enough. I was wondering if I was missing anything for the scripted case. That is, within
like if task A does commit! on a fileset that will change the classpath for the other task
doing an advanced compile of 3
.cljs.edn builds on circleci -- anyone want to guess the duration?
@micha: with some sort of higher order task it should be possible to merge two filesets that have been computed in parallel and
commit! the merged one, right?
for pods to be in the cloud and to be the same as a local pod, the evals need to happen in the same order
like with castra, i think it would probably be better to cleanly delineate the limitations
So over on IRC the other day I was asking about getting ENV vars that I "stub" with Environ into a pod where my boot-test task is running. Any ideas?
I tried just creating a clojure.test around fixture that uses
with-redefs on environ/env but by the time that's actually running for a test is too late in the process; it needs to be there before the namespace is interpreted for the test run
I looked at the README, but I wasn't quite sure how that's gonna help me keep config out of my source
Maybe I should take a step back in my problem and see if I'm missing a better overall solution.
I'm writing a Clojure web app that talks to Postgres, and trying to write a test suite for it. Because I'll eventually be deploying to Heroku, the postgres connection info comes from ENV vars, and that's what I'd also like to use to distinguish between my development database and test database locally.
So I've got various builds set up in my build.boot, and I was using environ to set those env vars before running tasks.
And all that leads to not being able to pass in the test database to the test suite because the pod isolates it.
Ideally, I'd like to keep all that config out of anything that will ever run out on the server, so build.boot tasks that it won't run are fine for setting that, but I'm hesitant to have it in the source.
What I mean is I'm under impression boot blows the temporary directories away as soon as it is done with them, or am I wrong?
What I want is to keep that from happening - something I did doesn't work with
boot-cljs and I would want to explore the temporary directory to verify something.
not sure if that is all the files you are looking for, as I understand it is the fileset from the tasks before it
Yeah, that's not enough - the file I'm lookign for is created during cljs compilation and the compiler blows up before the task finishes
I thought they had to be cleared but that may just be from earlier tasks in the pipeline
@mathiasx: if you have JVM-global environment you can't store those in Clojure vars, because those only exist in a specific Clojure runtime
@flyboarder: nothing too fancy, just usual
boot-cljs invocation, I'm using custom clojurescript compiler though