@socksy: im not a heavy nix user unfortunately; still quite a beginner, so can't really help in this case

When I run boot -h, I get an error:

clojure.lang.ExceptionInfo: No such namespace: core
    data: {:file
           "/var/folders/z2/tkdntvps3z9fyvhxq34gdhkw0000gn/T/boot.user5676623024112027610.clj",
           :line 9}
java.lang.RuntimeException: No such namespace: core
               ...
boot.main/-main/fn     main.clj: 169
   boot.main/-main     main.clj: 169
               ...
  boot.App.runBoot     App.java: 361
     boot.App.main     App.java: 441
               ...
  boot.Loader.main  Loader.java: 253

should this command be dependent on my build.boot?

@jethroksy: does it happen when you do boot -BP -h?

that's how you can test the theory

nope

Hello guys, having an issue with boot.core/json-parse:

boot.user> (boot.core/json-parse "{\"a\":1}")
{"a" 1}

boot.user> (boot.core/json-parse "{\"a\":1}" keyword)
java.lang.RuntimeException: No reader function for tag function

boot.user> *data-readers*
{}

-B disables build.boot

-P disables profile.boot

cool

now you can do boot -B -h

i don't have a profile.boot

and boot -P -h to bisect the problem

i think

its a little sad that the clj file gets cleaned out

well for completeness

so I can't trace where the error is coming from

you can do boot -b

or boot -vb

to see the file

is this documented somewhere?

-v will pretty print, which changes line numbers

sure, boot -h

so if you do boot -vh

ah right but that didn't work hahaha

and it fails with some line number

thanks!

will note in future

you can then do boot -vb

and see the boot script

boot -vb |cat -n

woah that's really cool

oh nevermind, for some reason doc led me to believe that the second argument was a function:

boot.user=> (doc boot.core/json-parse)
-------------------------
boot.core/json-parse
([x & [key-fn]])
  Same as cheshire.core/parse-string.

but actually:

boot.user> (boot.core/json-parse "{\"a\":1}" true)
{:a 1}

yeah that docstring is copied from the cheshire function it's wrapping

it just calls the cheshire function in a pod

Hi. Has anyone successfully used Adzerk's cljs-repl task with boot version > 2.5? I'm trying but keep getting missing file errors and was wondering whether it is just me.

what missing files?

are your stuff in the :source-path or :resource-path

Filesystem: touching main.out/cljs_deps.js... java.util.concurrent.ExecutionException: java.nio.file.NoSuchFileException: app/build/main.out/cljs_deps.js Works fine if I prepend BOOT_VERSION=2.4.2, but anything above that throws that error. I'll investigate it further, was just wondering whether someone else has seen it before.

@mjmeintjes: is app/build/main.out/... your target path?

My target path is app/build. It seems pretty strange - the first time I build everything is fine - files show up in the build directory. Then, when I start the repl with boot repl -c and (start-repl), it triggers a rebuild and throws that exception. app/build also seems to be empty.

is there a way to use boot-environ without committing certain env params into version control

@mjmeintjes: can you try using BOOT_EMIT_TARGET=no and add the target task?

like boot build target -d app/build

oh just realised danielsz's version was deprecated

@jethroksy: Hi, did you have trouble with it?

i'm wondering what's the equivalent of profiles.clj

In what sense?

i want to pull in envs but not commit them to version control

i tried creating a profiles.clj in the root dir but it doesn't get pulled in

Ah, yes, I do that with boot-runit

Oh, wait, just a sec

No, I don't do that. I commit env to a private repo.

@jethroksy: the boot equivalent is ~/.boot/profile.boot and ./profile.boot (re: your question about profile.clj)

i saw the wiki re profile.boot and configure-repositories!

yep

but still clueless about how to use it with environ

since profiles.clj is just a map

@micha That worked. I previously tried adding the target task, but it only seems to work if you add the target task and include BOOT_EMIT_TARGET=no. Thanks a lot - you probably saved me a few hours of debugging!

will it work the same way?

@mjmeintjes: i think there is a bug with the older target task on windows (you're on windows right?)

No - Linux VM.

@jethroksy: profile.boot is evaluated in your build script

it's evaluated before the contents of build.boot

but in the same process

you can put any clojure code in there

so i could just

(def envs {...})

@mjmeintjes: linux vm on windows host?

and refer to it in my build.boot

you could, yes

@micha - Yes - Ubuntu VM (VirtualBox) running on Windows 8

yeah i think that's the windows issue

boot -vb doesn't preprocess profiles.boot?

yes it does

it's profile.boot

oops typo here

we should have chosen a completely different name i think

i got it right in my repo though

it should have been like rc.boot or something

but code from there doesn't show up

where did you put the file?

same dir as build.boot

boot inserts comments to separate the different sections

you can see the global profile there (~/.boot/profile.boot) and the local profile (./profile.boot)

I don't have that that unfortunately

i don't have a build.boot in this directory

which version of boot?

2.4.2

ah

should probably upgrade

yeah boot -u

the local profile was introduced with 2.5.0

ah

upgrading now

thanks!

I see it now

this is actually way cleaner than profiles.clj

no need for deeply nested maps

yes we can program in there!

works like a charm

the target task is typically the first task in comp right?

no it needs to be near the end or at the end

it won't see anything created by tasks that come after it in the pipeline

boot tasks compose like transducers

left to right

i was under the impression that all it did was change some preset variable

conj PATH ...

all what did?

(target :dir #{"target"})

that writes all output files in the fileset to the directory "target"

and it gets that fileset from the task before it

does including it mute the deprecation warning

no, you need to set the env var (or add to your boot.properties file) boot_EMIT_TARGET=no

BOOT_EMIT_TARGET=no

I see, thanks!

you can suppress all deprecation warnings with BOOT_WARN_DEPRECATED=no

but if you heed the warnings you won't have any issues upgrading to boot 3.0.0 whenever that is

it won't be for quite some time

doesn't make sense to suppress them

@jethroksy: One thing that took me a while to grok with Boot is that when you see something like (comp (task1) (task2) (task3)), those tasks are typically structured as

(deftask some-task []
  (set-env! ...) ;; dependencies, sources, resources, assets, etc
  some-function-for-the-task)

So the fileset is built first and is immutable, then the tasks execute in sequence in the context of that fileset.

(is that accurate @micha? it's what I understand based on our conversations)

@seancorfield: that's exactly right

and tasks create a new immutable version of the fileset and passes it to the next handler

is that right?

precisely

and they call commit! on it before passing it to sync the actual filesystem and clsspath with the immutable fileset

See, this is where you make things confusing @micha

which thing is confusing?

that seems clear to me

Because the initial fileset comes from all of the set-env! / merge-env! calls at the start of all the tasks being composed.

Because each task is called (evaluated) to obtain a function.

i mean to be precise the initial fileset comes from a snapshot of the actual filesystem directories managed by boot

So it looks like pure left-to-right composition but its composition of the result of calling the tasks.

which you can influence by calling set-env! to add source paths etc

yes, that's right

the benefit of doing it that way is that everything happens left to right

oh I see where the confusion can arise

which is i think pretty intuitive if you consider the command line

yeah it is

i think it's more intuitive to use tasks in boot than it is to make them

also another tradeoff, but i think a good one

(comp (task1) (task2) (task3)) means call each task first, then compose the results. So there are inherently two phases here. And whilst that's blindingly obvious when you think about it, it's easy to miss on the surface.

agreed

Question: does Clojure guarantee that in (func a b c) that a, b, c are guaranteed to be evaluated in that order?

i believe so, yes

yes i think so

which is why it isn't confusing

(I'm used to languages that don't guarantee arguments are evaluated left-to-right)

if you understand the semantics of task

One thing the docs don't make clear -- and I've talked with @micha about this -- is that calling set-env! / merge-env! inside a task body does unexpected things

i.e., "best practice" is to call those to build the initial fileset outside the function that each task returns.

yeah set-env! is the bluntest tool for managing mutable shared state in boot

in the pipeline you have a more granular tool in the fileset and the operations you can do on it

Once I learned that, life with Boot was way less painful

boot-expectations is pretty great btw

i'm going to use it for the boot tests i'm working on

Thanks. We like it at World Singles

i'd never seen that library before, good find

I saw a talk about Expectations at Clojure/West 2012 and by the end of the talk I'd started converting our clojure.test-based tests over to Expectations.

a very Lisp Can Do It vibe, it has

Within a week we'd converted everything except our WebDriver tests which are very procedural.

i was impressed that it wasn't just another plain english dsl attempt

The only thing I might criticize Expectations for is that Jay Fields can be a bit radical about feature changes.

like (given that a thing is true i should see something happen over there)

i like how it's the opposite of those

alan had the idea of using it for assertions in a program, which seems like a promising idea

the various equal-ish functions are clever

Between 2.1.3 and 2.1.4 Jay dropped expect-let -- which we relied on! -- because it had edge cases with weird behavior. So semantic versioning is not exactly his thing.

haha

need tests for the tests

oh i finally figured out the sql datetime thing

it's pretty insane and i'm surprised that more people aren't confused by it

Expectations has had a lot of API breakage over the years so you have to be careful about updating. But it is a really nice DSL.

Yeah, I know, SQL date/time things are horrible.

i'm surprised airplanes aren't falling out of the sky because of this

expectations doesn't even seem like a dsl to me, just well designed functions and macros

hwich is what i like about it

When we started building our global dating platform back in 2009 (a complete rewrite of the previous platform), everything we read said the only way to make it all work, regarding SQL date/time, was to have everything ntp-sync'd to UTC. Not just the O/S on every server, but also the DB software (since they can, rather insanely, be on different timezones!). Argh!

With Expectations, when you start doing complex tests, they still read nicely... (expect (more pred1 pred2 pred3) (produce-actual-value)) for example.

But the SQL date/time thing is like one of the most frequently asked questions about java.jdbc... 😞

the default is totally insane

and the tricky part is that on any one machine you can't detect the error

you need to have two clients in different timezones writing to the database

then each will see the other's writes as crazy times

but their own will look fine

Yeah, if you have a cluster, it's a pain.

like even if you do mandate that all servers are on utc, which is sane, you still end up running some script or program on a workstation to import some data or whatever

an dboom, timebomb armed

hi @jaredly

hi!

Welcome!

@micha: Yeah, you really have to be super careful about interacting with a database. We have everything except developer workstations running on UTC ntp-sync'd and we only ever run updates from a server. When we do interact from a workstation, we use a REPL into the server so the code we run for the data migration is actually running on the server not the client.

i used your handy protocols, the ISQLValue and friends to fix it

because i *know* that all the dates in the database are UTC

so i just have to unfubar the client

I’m really enjoying boot’s docs — well done, whoever’s responsible!

🍻 to everyone!

it's awesome how many people contributed

It's funny, I tried Boot a few years back (when I was organizing the first ClojureBridge workshop) and it was... a less than ideal experience... It's phenomenal how far Boot has come. Boot 2.5.x is night and day compared to whatever version was current back then. So part of me feels a bit guilty for being so negative about Boot back then, hence my very positive support for it now

I will be writing up our switch from Leiningen to Boot for my blog soon.

Our ops folks are working with figuring out how to deploy our app to clusters of Docker containers right now and I got a message loud and clear today that they like Boot and don't like Ant and want us to aggressively move more and more of our build processes to Boot...

does boot-sassc work in 2.5.5?

I get feedback Compiling main.scss, but no css files are actually generated

I have a feeling its the target dir thing

@jethroksy: You could try running it with debug (`-vvv`) and it should print out the sassc command it is running

With a quick look I don't think boot-sassc depends on target dir

Also, there is a alternative sass task: https://github.com/Deraen/sass4clj it doesn't need the sassc to be available

@juhoteperi thanks will try in a while. I took a look at your sass plugin but it didn't look like it supports compiling specific files

Hmm

What's your use case?

The .main postfix is maybe a bit strange with scss as as far as I know it's common to regard any scss/sass files without _ prefix as "main" files

micha: I was investigating further, and it seems that head.sh has been added to the beginning of a file called .boot-wrapped which is called by the boot binary itself

so then boot.app.path is to the .boot-wrapped file, which is incorrect, and causes shebang? to fail

the stuff in the initial boot file is setting the JVM etc, so if I change the shebang to use the .boot-wrapped directly it fails

not sure what the solution is here, or what's creating the .boot-wrapped script in the first place (is it specific to the NixOS installation?)

I did open a support request at CircleCI about how to cache build time dependencies

@juhoteperi oh it ended up compiling and copying every file including my partials

I don't mind the .main postfix at all

@jethroksy: That's strange. It should only compile files with .main postfix.

I'll try again on another computer later

I moved the boot-cljs documentation from readme to wiki. Improvements welcome

@juhoteperi: ok it seems to only compile the main file now, but is there a way to output it in a directory that i want like resources/public/css

Hi, i recently tried out cursive. I also use datomic-pro installing peer libs with boot works fine, installing peer libs with lein(needed for cursive) also works fine after adding the ~/.lein/credentials.clj.gpg AND deleting the ones i installed with boot every time i switch between boot and lein i have to delete and reinstall again. what worked fine in the end was to delete the ~/.m2/…datomic-pro libs and install them via maven-install not sure if its worth mentioning on the wiki “for cursive users” the related error message in cursive is just everything fails, but when you try out a lein deps you get:

~/e/api> lein deps
Could not transfer artifact com.datomic:datomic-pro:pom:0.9.5344 from/to  (): Failed to transfer file: . Return code is: 204, ReasonPhrase: No Content.
This could be due to a typo in :dependencies or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment variable.

clojure.lang.ExceptionInfo: Failed to collect dependencies for [#object[org.sonatype.aether.graph.Dependency 0x13df2a8c "org.clojure:clojure:jar:1.7.0 (compile)"] #object[org.sonatype.aether.graph.Dependency 0x1ebea008 "com.datomic:datomic-pro:jar:0.9.5344 (compile)"] #object[org.sonatype.aether.graph.Dependency
…

@jethroksy: You can either move your source file to similar path (something like src/scss/public/css/style.main.scss) or use sift task to move file

@peterromfeld: Is your repo alias/id the same in lein and boot? There was recently some talk that aether uses the repo id for something

boot and lein both go into ~/.m2/repository

repo id is the key in Lein repositrories map and first part of repo tuple in Boot

the project.clj is generated with boot lein-generate from https://github.com/boot-clj/boot/wiki/For-Cursive-Users so i guess its the same? sorry not sure what you mean

Hmm, I don't think that code adds :repositories to project.clj at all

ah ok i understand

That could be the problem, if you have not defined the datomic repo in global lein profile

yes that one i added manually

in boot profile its using a regex with #”my\.datomic\.com” and in the project.clj its just using a string “http://my.datomic.com"

@juhoteperi boot-sassc works on my desktop

oh well

i run arch on my desktop, but OSX on my macbook

@peterromfeld: I don't think regex is the key but it's used to match against repo url for credentials?

project.clj:

:repositories {""
                 {:url   ""
                  :creds :gpg}}

(set-env!
 :repositories #(into [
 ["datomic" {:url ""
 :username “us[email protected]" :password “xxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"}]
 ] %))

Okay so repo id is "http://my.datomic.com" in project.clj and "datomic" in boot

oh yeah thanks lol

sry for bother

Not sure if that's the cause but it's worth to try

let me try

you could use boot -vb to see your resultant boot file

yup it indeed fixed the issue, thanks so much

@micha: Was some way to tell Boot about task failure invented which doesn't require throwing an exception?

Boot-cljs could use more control in reporting the errors (could have option to throw the exeptions for debugging, but for normal use they are unncessarily verbose)

@juhoteperi: not yet, boot-test is where research is being done, feedback and ideas very welcome

it would be nice to roll something out as an alpha test with 2.6.0

any ideas you have about it would be awesome

maybe a wiki page for the design?

I think I saw fileset metadata being mentioned?

i find it kind of hard to follow long issue comment chains

yeah that's the main idea so far

but really it's an open problem

Yeah

i think we could make something really great though, it's a problem very well suited to the way boot works

hi @shanekilkelly

Hi

welcome!

thanks!

@jethroksy: I should update sass4clj to use latest jsass. Thery have rebuild the native libraries for OS X (multiple times) so maybe that would fix it on OS X.

Hello guys, I was wondering if I can clone a git repo in boot (if there is a library, alternatively I will use Java interop I guess)

you can clone git repos from clojure either by shelling out or by using jgit

Ok great tnx I thought of asking but I was going in that direction (jgit)

np. boot actually has jgit inside and exposes a few functions for querying the status of repos - https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/git.clj

but jgit is running in boot's "worker pod" so as to not conflict with your project's dependencies

great thanks for the hint, will have a look for inspiration, basically what I need to do is to clone git repos and then include their source as fileset to then deploy somewhere

where somewhere can be left as separate task (for instance s3)..

maybe there is already some facility for this as it sounds a pretty common task

cool - yeah i can imagine oyu can git clone to a tmpdir, then add that dir to the fileset

this will be my first boot project so I will ask some question I guess

@richiardiandrea: boot has a built-in task, add-repo

@richiardiandrea: https://github.com/boot-clj/boot/blob/master/doc/boot.task.built-in.md#add-repo

oh great! so i just need to clone the repos i want basically then filter out the files i do not want from the output file set

that works on the current project

not sure if it will do other git repos as well

but you can modify it to make a task that does what you need

just a question, what is the status of figwheel and boot? is this a project people are effectively using? -> https://github.com/aJchemist/boot-figwheel

I also found this, sorry for the noise https://github.com/bhauman/lein-figwheel/issues/174

@richiardiandrea: I think most boot users use boot-reload https://github.com/adzerk-oss/boot-reload instead of trying to finagle figwheel to work with boot

Also boot-cljs-repl for the repl part of figwheel

@richiardiandrea: yes I do use boot-realod, boot-cljs, boot-cljs-repl, boot-test and boot-cljs-test (which includes doo without even configure it) to have an augumented TDD. These guys working on boot are given me back my LISP machine of 30 years ago. Keep on doing this great work

Thanks guys I am checking Jamal and everything is pretty slick ;)