Fork me on GitHub
#boot
<
2016-01-19
>
dviramontes00:01:35

hi all, does anyone know where to find documentation for the *sift* boot task ? im trying to make a boot task to move files from the target directory to the root of the project.

richiardiandrea00:01:50

sorry for the snipped I have a problem

richiardiandrea00:01:05

I have a problem in understanding with-eval-in it is weird it always returns nil but in the case of my function not executing in the pod everything is fine...moreover, no util/info or dbug works in a pod (is it expected?)

micha00:01:38

@richiardiandrea: dbug etc should work in a pod

micha00:01:25

the expression you evaluate in the pod must not evaluate to anything that isn't printable

micha00:01:31

or you will get nil as a result

richiardiandrea00:01:24

I was returning a list of java.io.File

micha00:01:58

dbug won't print anythjing unless you set -v option

micha00:01:13

or (swap! boot.util/*verbosity* inc)

richiardiandrea00:01:05

yes I put verbosity 3 in any case, I think I still need to learn a bit here and a bit there πŸ˜‰

micha00:01:45

a tricky thing is that the boot.util namespace in the pod isn't exactly the same as the main one

micha00:01:57

it's a different, separate copy, just for that pod

micha00:01:10

so your verbosity settings are copied in by boot when you create the pod

richiardiandrea00:01:11

about the dbug outside the pod, I had to add slf4j-simple

richiardiandrea00:01:28

there was just a warning

micha00:01:37

what did the warning say?

richiardiandrea00:01:15

the classic warning...about the fact that it cannot find SLF4J Static...i don't remember, I can disable one sec in build.boot

micha00:01:37

boot doesn't use the java logging facilities for that

richiardiandrea00:01:51

and by the way it was version 1.7.2 no others πŸ˜„

richiardiandrea00:01:04

weird indeed, maybe jgit

micha00:01:36

strange, yeah

micha00:01:44

boot just does printf for that

micha00:01:53

oh, i wonder if it's something with boot-test

micha00:01:55

it does some things with junit

micha00:01:11

which could be creating some logging entanglements

richiardiandrea00:01:03

I should see it in the deps tree maybe

richiardiandrea00:01:08

[clj-jgit "0.8.8"]
β”œβ”€β”€ [com.jcraft/jsch "0.1.52"]
β”œβ”€β”€ [fs "1.3.2"]
β”‚   └── [org.apache.commons/commons-compress "1.3"]
└── [org.eclipse.jgit/org.eclipse.jgit.java7 "3.7.0.201502260915-r" :exclusions [[com.jcraft/jsch]]]
    └── [org.eclipse.jgit "3.7.0.201502260915-r"]
        β”œβ”€β”€ [com.googlecode.javaewah/JavaEWAH "0.7.9"]
        β”œβ”€β”€ [org.apache.httpcomponents/httpclient "4.1.3"]
        β”‚   β”œβ”€β”€ [commons-codec "1.4"]
        β”‚   β”œβ”€β”€ [commons-logging "1.1.1"]
        β”‚   └── [org.apache.httpcomponents/httpcore "4.1.4"]
        └── [org.slf4j/slf4j-api "1.7.2"]

jaredly00:01:05

what is the β€œtarget” task? Can’t find docs about it

micha00:01:37

you can do boot target -h at the command line, or (doc target) in a repl

micha00:01:02

boot -h will print all the currently available tasks

micha00:01:55

also all the built-in tasks are documented in the api docs here: https://github.com/boot-clj/boot/blob/master/doc/boot.task.built-in.md

jaredly00:01:15

ahhhh awesome. that’s what I was looking for. thanks!

jaredly00:01:38

is it weird that something called :dir is of type set of strings πŸ˜„

micha00:01:01

yeah it should be :dirs

seancorfield03:01:29

I was wondering about that: several array/set arguments that I've seen on Boot tasks seem singular...

seancorfield03:01:33

Like aot and namespace, pom and license, push and file-regex...

jaredly05:01:31

how possible would it be to make a boot install task that can be used like npm install? as in boot install [email protected], and it modifies build.boot + installs the lib

seancorfield06:01:44

Well, there's a lot of different ways to add a new project dependency...

seancorfield06:01:39

If you have (set-env! :dependencies ...) in your project build.boot at the top level, it's as simple as adding [some-project "1.2.0"] so I'm not sure whether it's worth a task for that little bit of editing?

ska08:01:56

Hi. I don't get the target task, yet. Do I need to call it between uber and jar or at the very end of my pipeline to create an uberjar?

pesterhazy09:01:02

@ska, at the very end, afaik

pesterhazy09:01:28

the order of tasks in comp is still back magic to me (the comparison to transducers doesn't exactly make it clearer to me)

pesterhazy09:01:08

idea for a blog post maybe? simple_smile

ska12:01:54

@pesterhazy: thanks. But I am still getting the deprecation warning

martinklepsch12:01:15

@ska: I think the warning tells you how to suppress it

martinklepsch12:01:41

if you have a boot.properties file you can add BOOT_EMIT_TARGET=no

laforge4914:01:51

Trying to figure out testing. I saw this and I'm wondering what is the X.Y.Z? (set-env! :dependencies '[[adzerk/boot-test "X.Y.Z" :scope "test"]])

micha14:01:15

it's the version of boot-test you are using

laforge4914:01:28

OK, I've got a dev-resources directory for the logger. With lein I didn't need to specify it. In boot, do I make it a source?

laforge4914:01:22

Bingo! (set-env! :source-paths #(conj % "test/clj" "dev-resources"))

pesterhazy14:01:59

@laforge49: the logger configuration xml should be in resources, not sources (if that's what you mean)

laforge4914:01:30

This works: (set-env! :resource-paths #(conj % "dev-resources"))

laforge4914:01:05

Or actually, this: (deftask testing "Profile setup for running tests." [] (set-env! :source-paths #(conj % "test/clj")) (set-env! :resource-paths #(conj % "dev-resources")) identity)

nonrecursive14:01:29

I wonder if it makes sense to fork boot-notify? it’s nifty but that 2.5 patch has been sitting around for awhile

micha14:01:34

there is a PR for boot that should be merged that incorporates some things

nonrecursive14:01:49

cool even better πŸ˜„

micha14:01:55

it's a little tricky though, which is why it's been on hold

pesterhazy15:01:22

@laforge49: you could add it to the snippets section on the wiki: https://github.com/boot-clj/boot/wiki/Snippets

juhoteperi16:01:14

@laforge49: Another solution for test resources is to put them into :source-paths, this way you don't need to call set-env! in a task. Files in :source-paths are not copied into jar.

juhoteperi16:01:45

it should be safe to add both "test/clj" and "dev-resources" to :source-paths in top-level because the files are not included in jar.

juhoteperi16:01:08

Though depending on your tasks, it is possible that some of your tasks will see the files and do something with them.

laforge4916:01:24

but resource-paths are copied?

juhoteperi16:01:01

Yeah, the difference betwheen source-paths and resource-paths is that files in resource-paths will be present in "output" (e.g. jar): https://github.com/boot-clj/boot/wiki/Filesets#fileset-components

laforge4916:01:41

but the items in source-paths will be compiled and the binary included in the jar, no?

juhoteperi16:01:25

If you AOT compile ALL namespaces, but I don't think that's very common

juhoteperi16:01:43

I usually just AOT compile the main namespace

laforge4916:01:36

so unless you aot, items in the source-path will not be included at all in the jar. Seems a bit strange.

juhoteperi16:01:02

Yeah, it's a bit confusing as the terms are same as in Lein (and Maven) but they work differently

laforge4916:01:06

Ah, for clojurescript, you always aot.

juhoteperi16:01:38

Yeah, for apps, but Clj and Cljs libs are just distributed as src

laforge4916:01:29

oh! So I should only use the cljs compile task for testing then.

laforge4916:01:45

slowly slowly

laforge4916:01:53

Many thanks!

laforge4916:01:00

yeah, I'm working my way through that. Is WAY over my head.

richiardiandrea17:01:47

Can I use sift using another directory (custom) as source?

richiardiandrea17:01:14

(and hello guys)

micha17:01:07

@richiardiandrea: the sift task only works on the fileset

micha17:01:20

it doesn't really know anything about files or directories

richiardiandrea17:01:55

@micha that's a pity, it is really handy, would you consider a --source option?

micha17:01:12

it would be a completely different thing

micha17:01:18

the sift task does no I/O at all

micha17:01:32

and it doesn't have any filesystem code in it

micha17:01:58

what are you wanting to do?

richiardiandrea17:01:14

ah ok, yes I wanted to reuse the filtering by regex part of sift and "linking" some part of my files from a temp dir to the fileset, I am using now by-re and not-by-re

richiardiandrea17:01:49

but then I have no way to use add-resource on each java.io.File

richiardiandrea17:01:22

so at the moment I have to filter files, then delete what I don't want from the temp dir

richiardiandrea17:01:38

and then add-resource my-dir

micha17:01:06

all of the add-* functions take a keyword arg :include or :exclude

micha17:01:11

so you can do like

micha17:01:50

(-> fileset (add-resource tmpdir :include #{#"^foo"}) commit!)

micha17:01:04

i think that might solve your issue?

micha17:01:06

its not completely documented, but it's in the arglist (little by little)

richiardiandrea17:01:25

oh wow wonderful

richiardiandrea17:01:35

that saves my chickens

micha17:01:07

also :mergers which can be used to resolve conflicts with files that are already in the fileset with the same name as a file you're adding

richiardiandrea17:01:29

yes that option is very neat indeed

micha17:01:35

otherwise it just overwrites

micha17:01:58

πŸ’―

micha17:01:21

@richiardiandrea: the options are documented in the uber task docstring

micha17:01:41

the uber task passes those options directly to add-resource

micha17:01:39

except of course the defaults mentioned there are only default for the uber task, not for add-resource

micha17:01:52

like standard-jar-mergers etc

richiardiandrea17:01:17

@micha ok that's a perfect starting point thanks

richiardiandrea17:01:35

I will copy from there and put in add-*