Clojurians
#boot
<
2016-01-06
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

onetom02:01:35

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

jethroksy02:01:12

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

jethroksy02:01:32

should this command be dependent on my build.boot?

micha02:01:09

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

micha02:01:20

that's how you can test the theory

escherize02:01:27

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*
{}

micha02:01:31

-B disables build.boot

micha02:01:37

-P disables profile.boot

micha02:01:52

now you can do boot -B -h

jethroksy02:01:59

i don't have a profile.boot

micha02:01:01

and boot -P -h to bisect the problem

jethroksy02:01:13

its a little sad that the clj file gets cleaned out

micha02:01:15

well for completeness :simple_smile:

jethroksy02:01:20

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

micha02:01:36

you can do boot -b

micha02:01:40

or boot -vb

micha02:01:48

to see the file

jethroksy02:01:58

is this documented somewhere?

micha02:01:01

-v will pretty print, which changes line numbers

micha02:01:07

sure, boot -h :simple_smile:

micha02:01:15

so if you do boot -vh

jethroksy02:01:18

ah right but that didn't work hahaha

micha02:01:21

and it fails with some line number

jethroksy02:01:29

will note in future

micha02:01:29

you can then do boot -vb

micha02:01:36

and see the boot script

micha02:01:42

boot -vb |cat -n

jethroksy02:01:22

woah that's really cool

escherize02:01:48

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.

escherize02:01:03

but actually:

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

micha02:01:24

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

micha02:01:34

it just calls the cheshire function in a pod

mjmeintjes02:01:53

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.

jethroksy02:01:01

what missing files?

jethroksy02:01:17

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

mjmeintjes02:01:16

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.

micha02:01:01

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

mjmeintjes02:01:05

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.

jethroksy02:01:52

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

micha03:01:47

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

micha03:01:57

like boot build target -d app/build

jethroksy03:01:12

oh just realised danielsz's version was deprecated

danielsz03:01:28

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

jethroksy03:01:16

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

danielsz03:01:56

In what sense?

jethroksy03:01:13

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

jethroksy03:01:30

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

danielsz03:01:45

Ah, yes, I do that with boot-runit

danielsz03:01:07

Oh, wait, just a sec

danielsz03:01:40

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

micha03:01:52

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

jethroksy03:01:16

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

jethroksy03:01:38

but still clueless about how to use it with environ

jethroksy03:01:42

since profiles.clj is just a map

mjmeintjes03:01:52

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

jethroksy03:01:53

will it work the same way?

micha03:01:32

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

mjmeintjes03:01:44

No - Linux VM.

micha03:01:04

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

micha03:01:16

it's evaluated before the contents of build.boot

micha03:01:19

but in the same process

micha03:01:30

you can put any clojure code in there

jethroksy03:01:50

so i could just

jethroksy03:01:59

(def envs {...})

micha03:01:00

@mjmeintjes: linux vm on windows host?

jethroksy03:01:34

and refer to it in my build.boot

micha03:01:02

you could, yes

mjmeintjes03:01:41

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

micha03:01:03

yeah i think that's the windows issue

jethroksy03:01:43

boot -vb doesn't preprocess profiles.boot?

micha03:01:16

yes it does

micha03:01:22

it's profile.boot

jethroksy03:01:39

oops typo here

micha03:01:53

we should have chosen a completely different name i think

jethroksy03:01:58

i got it right in my repo though

micha03:01:07

it should have been like rc.boot or something

jethroksy03:01:17

but code from there doesn't show up

micha03:01:31

where did you put the file?

jethroksy03:01:51

same dir as build.boot

micha03:01:02

boot inserts comments to separate the different sections

micha03:01:36

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

jethroksy03:01:44

I don't have that that unfortunately

micha03:01:49

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

micha03:01:59

which version of boot?

jethroksy03:01:48

should probably upgrade

micha03:01:49

yeah boot -u

micha03:01:03

the local profile was introduced with 2.5.0

jethroksy03:01:32

upgrading now

jethroksy03:01:59

I see it now

jethroksy03:01:20

this is actually way cleaner than profiles.clj

jethroksy03:01:34

no need for deeply nested maps

micha03:01:33

yes we can program in there!

jethroksy03:01:28

works like a charm

jethroksy03:01:16

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

micha03:01:33

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

micha03:01:53

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

micha03:01:00

boot tasks compose like transducers

micha03:01:06

left to right

jethroksy03:01:42

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

jethroksy03:01:48

conj PATH ...

micha03:01:55

all what did?

jethroksy03:01:11

(target :dir #{"target"})

micha03:01:31

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

micha03:01:48

and it gets that fileset from the task before it

jethroksy03:01:14

does including it mute the deprecation warning

micha03:01:42

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

micha03:01:52

BOOT_EMIT_TARGET=no

jethroksy03:01:00

I see, thanks!

micha03:01:15

you can suppress all deprecation warnings with BOOT_WARN_DEPRECATED=no

micha03:01:45

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

micha03:01:49

:simple_smile:

micha03:01:54

it won't be for quite some time

jethroksy03:01:16

doesn't make sense to suppress them :simple_smile:

seancorfield04:01:44

@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 all the set-env! calls happen to set up the fileset, and then the actual task bodies are executed...

seancorfield04:01:23

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

seancorfield04:01:49

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

micha04:01:37

@seancorfield: that's exactly right

jethroksy04:01:12

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

jethroksy04:01:18

is that right?

micha04:01:13

precisely

micha04:01:44

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

seancorfield04:01:49

See, this is where you make things confusing @micha :simple_smile:

micha04:01:05

which thing is confusing?

jethroksy04:01:16

that seems clear to me

seancorfield04:01:36

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

seancorfield04:01:01

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

micha04:01:16

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

seancorfield04:01:24

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

micha04:01:29

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

micha04:01:04

yes, that's right

micha04:01:56

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

jethroksy04:01:01

oh I see where the confusion can arise

micha04:01:14

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

micha04:01:19

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

micha04:01:28

also another tradeoff, but i think a good one

seancorfield04:01:35

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

seancorfield05:01:20

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

micha05:01:32

i believe so, yes

jethroksy05:01:32

yes i think so

jethroksy05:01:41

which is why it isn't confusing

seancorfield05:01:04

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

jethroksy05:01:04

if you understand the semantics of task

seancorfield05:01:58

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 :simple_smile:

seancorfield05:01:29

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

micha05:01:17

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

micha05:01:44

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

seancorfield05:01:49

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

micha05:01:26

boot-expectations is pretty great btw

micha05:01:46

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

seancorfield05:01:03

Thanks. We like it at World Singles :simple_smile:

micha05:01:09

i'd never seen that library before, good find

seancorfield05:01:31

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.

micha05:01:35

a very Lisp Can Do It vibe, it has

seancorfield05:01:55

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

micha05:01:12

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

seancorfield05:01:21

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

micha05:01:37

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

micha05:01:03

i like how it's the opposite of those

micha05:01:00

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

micha05:01:49

the various equal-ish functions are clever

seancorfield05:01:21

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.

micha05:01:15

need tests for the tests

micha05:01:02

oh i finally figured out the sql datetime thing

micha05:01:27

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

seancorfield05:01:47

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.

seancorfield05:01:04

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

micha05:01:27

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

micha05:01:11

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

micha05:01:18

hwich is what i like about it

seancorfield05:01:16

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!

seancorfield05:01:13

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

seancorfield05:01:13

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

micha05:01:42

the default is totally insane

micha05:01:06

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

micha05:01:25

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

micha05:01:38

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

micha05:01:45

but their own will look fine

seancorfield05:01:51

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

micha05:01:54

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

micha05:01:04

an dboom, timebomb armed

micha05:01:17

hi @jaredly

seancorfield05:01:45

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

micha05:01:02

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

micha05:01:21

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

micha05:01:41

so i just have to unfubar the client

jaredly05:01:12

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

micha05:01:24

:beers: to everyone!

micha05:01:53

it's awesome how many people contributed

seancorfield05:01:19

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 :simple_smile:

seancorfield05:01:45

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

seancorfield05:01:45

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

jethroksy07:01:56

does boot-sassc work in 2.5.5?

jethroksy07:01:41

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

jethroksy07:01:52

I have a feeling its the target dir thing

juhoteperi13:01:02

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

juhoteperi13:01:06

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

juhoteperi13:01:04

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

jethroksy13:01:05

@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

juhoteperi13:01:58

What's your use case?

juhoteperi13:01:11

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

socksy14:01:24

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

socksy14:01:07

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

socksy14:01:36

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

socksy14:01:07

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

juhoteperi14:01:58

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

jethroksy14:01:08

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

jethroksy14:01:19

I don't mind the .main postfix at all

juhoteperi14:01:21

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

jethroksy14:01:49

I'll try again on another computer later

juhoteperi14:01:44

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

jethroksy15:01:15

@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

peterromfeld15:01:23

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.
also the other way around (installed with lein then afterwards run boot) you get the same error like you get in cursive when you installed it with boot first:
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
…

juhoteperi15:01:00

@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

juhoteperi15:01:19

@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

peterromfeld15:01:06

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

juhoteperi15:01:29

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

peterromfeld15:01:37

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

juhoteperi15:01:18

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

peterromfeld15:01:55

ah ok i understand

juhoteperi15:01:56

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

peterromfeld15:01:00

yes that one i added manually

peterromfeld15:01:55

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"

jethroksy15:01:04

@juhoteperi boot-sassc works on my desktop

jethroksy15:01:43

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

juhoteperi15:01:16

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

peterromfeld15:01:21

project.clj:

:repositories {""
                 {:url   ""
                  :creds :gpg}}
profile.boot:
(set-env!
 :repositories #(into [
 ["datomic" {:url ""
 :username “user@mail.xx" :password “xxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"}]
 ] %))

juhoteperi15:01:48

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

peterromfeld15:01:10

oh yeah thanks lol

peterromfeld15:01:15

sry for bother

juhoteperi15:01:37

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

jethroksy15:01:54

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

peterromfeld15:01:30

yup it indeed fixed the issue, thanks so much

juhoteperi15:01:31

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

juhoteperi15:01:04

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)

micha15:01:05

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

micha15:01:46

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

micha15:01:04

any ideas you have about it would be awesome

micha15:01:12

maybe a wiki page for the design?

juhoteperi15:01:23

I think I saw fileset metadata being mentioned?

micha15:01:31

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

micha15:01:52

yeah that's the main idea so far

micha15:01:03

but really it's an open problem

micha15:01:25

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

micha16:01:29

hi @shanekilkelly

shanekilkelly16:01:37

Hi :simple_smile:

juhoteperi16:01:03

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

richiardiandrea17:01:56

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)

alandipert17:01:16

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

richiardiandrea17:01:20

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

alandipert17:01:50

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

alandipert17:01:22

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

richiardiandrea17:01:54

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

richiardiandrea17:01:18

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

richiardiandrea17:01:40

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

alandipert17:01:37

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

richiardiandrea18:01:21

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

micha20:01:53

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

richiardiandrea20:01:43

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

micha20:01:08

that works on the current project

micha20:01:22

not sure if it will do other git repos as well

micha20:01:34

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

richiardiandrea20:01:49

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

adamfrey20:01:30

@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

martinklepsch21:01:57

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

magomimmo21:01:25

@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

richiardiandrea21:01:55

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