Fork me on GitHub
#boot
<
2015-12-26
>
magomimmo10:12:09

@crisptrutski: you did an awesome job with https://github.com/crisptrutski/boot-cljs-test and I really appreciated a lot your support in guiding me at using it in the proper way.

codemartin12:12:14

Recently boots jar task started outputting my program into the file ./target/project.jar instead of target/my-programs-name-0.1.5.jar. Why is this, and how can it be controlled? It also started putting a lot of stuff in ./target - some things about cljs which I'm not even using. It also complains I have no target task. Fair enough - but how do you add one? Searched for target in the wiki but found only .

nberger12:12:14

@codemartin about the target task not found, that task was introduced in boot 2.5.0, so it might be that one of your boot tasks assumes it exists but you are using an older version of boot so it's not available. Please check your boot version with boot -V

alandipert14:12:37

@codebeige: https://github.com/boot-clj/boot/blob/master/CHANGES.md has the answers you seek. re: project.jar, check out the file option of the jar task - you can name the jar explicitly with it

nberger16:12:57

@micha I just pushed the squashed commits to the junit PR. Also added two changes: it now saves the summary in the fileset metadata instead of creating a new file only for this purpose, and added a fix to avoid having the test counters mutiplied by two. More details are in the PR.

nberger17:12:26

I also kept thinking about your notifications idea... It sounds great as a new notification mechanism that might allow having multiple notification targets (stdout, inotify, slack?, etc), I guess that's where we would get the most benefit out of it. But I don't feel it should be related to this PR.

nberger17:12:32

It helps that now we are not introducing a new file for the test summary but just using the fileset metadata, so it's not that of a commitment that we wouldn't get rid of in the future (I understood from our conversation yesterday that you preferred to experiment with a new notification mechanism that would have other benefits instead of adding a new file to hold the summary and new tasks would start depending on that file, etc...)

micha17:12:46

@nberger: this looks great!

nberger17:12:41

@micha awesome, thanks!!

micha17:12:28

i'll bump the version to 1.1.0 and push to clojars

micha17:12:33

awesome work, thanks!

micha17:12:03

lol alan's test case

micha17:12:21

(ns adzerk.boot-test.test
  (:use clojure.test))

(deftest have-you-tried
  (is (= 1 1)))

juhoteperi18:12:29

Great! I've been waiting for junit output.

juhoteperi18:12:55

Then if someone would implement Cloverage for Boot simple_smile

seancorfield19:12:22

A question about the Boot file system abstraction… I had a need to download a specific set of dependencies (JARs) and then copy them into specific folders within the project. Those folders exist and already have a bunch of files in them which I don’t want touched. I also don’t want any other files copied into those folders but the specific dependencies I specify.

seancorfield19:12:59

I tried to do it just via the Boot fs but couldn’t get it to exclude all the default dependencies in the main project...

micha19:12:15

when you say "within the project" you mean directories under source control? like actually in your project?

seancorfield19:12:37

Well, they’re excluded folders, but they are actually in the project.

micha19:12:24

you probably want to use http://clojure.java.io/copy there

micha19:12:42

are the jars you're downloading in a maven repo?

seancorfield19:12:46

That’s what I ended up doing but I’d expected to be able to do it via just the Boot fs abstraction.

micha19:12:58

by "fs" you mean filesets?

seancorfield19:12:00

That they’re JARs is irrelevant really.

seancorfield19:12:08

Yes, just too lazy to type that out simple_smile

micha19:12:28

yeah the fileset abstraction is isolated from your project

micha19:12:36

it can't know anything about your project at all

micha19:12:47

this prevents boot from clobbering anything important to you

seancorfield19:12:57

Even with the target task?

micha19:12:00

and lets tasks do whatever manipulations and transformations they want

micha19:12:15

the target task can be used to achieve what you want, actually

micha19:12:26

because that will emit to any directory you choose

micha19:12:36

you want to use the --no-clean option though!

micha19:12:49

or it will remove all the things already in there!@

micha19:12:15

and the sift task to fileter out any files in the fileset you don't want to write to that directory

seancorfield19:12:52

Maybe I’ll have another go at it next week. It just seemed harder than I expected.

seancorfield19:12:12

I was hoping the Boot cp function would do what I wanted but I couldn’t figure out how to get the TmpFile for the destination so there’s something about the abstraction I’m not getting...

micha19:12:52

those functions, like cp are to move things around inside the fileset

micha19:12:17

the target task is the only thing in boot that will create files in a named directory

micha19:12:30

everything else deals with anonymous files and directories

micha19:12:19

manipulating the project itself is somewhat beyond the scope of boot itself

micha19:12:46

usually i'd make a Makefile or shell script if the project itself needs to be initialized

seancorfield19:12:28

So suppose I have some folder X (in the project) that contains some files, and I want to do something (to tell Boot about some new input files), and I want those sync’d / copied into folder X — without deleting any other files from X and without adding anything except the specific new input files — is that doable with Boot primitives?

seancorfield20:12:13

It seems like I could use target —no-clean as long as I can limit the scope of the input files to just the new files...

micha20:12:53

you can use the sift task before the target task to whitelist/blacklist files

seancorfield20:12:05

OK. I tried setting source paths and resource paths to empty sets but the project values already took effect simple_smile

micha20:12:34

you should be able to do that dynamically

micha20:12:06

i see, this is weird

micha20:12:14

it should work, but it does not

micha20:12:19

interesting yeah that's a bug

micha20:12:30

it's not correctly removing the files from the classpath

seancorfield20:12:39

Yay me! I found a bug! simple_smile

seancorfield20:12:16

OK, thank you. That confirms that what I was trying to do should have worked so my understanding of the fs abstraction isn’t as floored as I thought it was.

micha21:12:48

aw, you took @marty.penner 's 🍻 away

flyboarder21:12:10

but now i feel bad

micha21:12:20

🍻 there we go

flyboarder21:12:54

yay 🍺 for everyone 😄

flyboarder21:12:21

can you explain that part a bit?

micha21:12:04

that part adds the non-transitive depdencies of the checkout project to the consuming project

micha21:12:15

non-transitive meaning the ones in their direct dependencies

micha21:12:46

at the end it prefers your versions of those, if you have the same deps already specified in the consumer's build.boot

micha21:12:53

(the dependency-loaded? part)

micha21:12:46

the resolve-nontransitive-dependencies function returns the dependency coordinates (like [foo/bar "1.2.3"]), but also the path to the jar in local maven

micha21:12:55

that's why line 95 is there

flyboarder21:12:21

so the checkout deps are never actually added as deps at all then? just to the fileset

micha21:12:47

well you might have them in your project dependencies

micha21:12:55

and you want to remove them in that case

flyboarder21:12:03

which is why the ones in your deps are chosen over them?

micha21:12:07

so that place isn't the right place actually

micha21:12:22

you want to remove the deps around line 105 i guess

flyboarder21:12:06

yeah thats what I was doing, i just didnt see the deps get used at all which are being passed in other than as files

micha21:12:31

(set-env! :dependencies #(into (vec (filter not-checkout? %)) (vec deps)))

micha21:12:55

where not-checkout? is a predicate that decides if a depenbdency is one of the checkout deps

flyboarder21:12:00

oh that makes way more sense than the maps I was working with XD

micha21:12:49

you can probably make something like

micha21:12:02

i dunno a set of deps symbols

micha21:12:10

and check set membership

flyboarder21:12:06

mhm, ill give that a go

seancorfield21:12:07

I notice that the boot.sh downloadable from the site has changed. Is there a way to ask the shell file what version it is, independent of Boot itself?

seancorfield21:12:11

(I already updated our copy for work but figured I’d ask, just for future reference)

micha21:12:18

@seancorfield: it doesn't expose its own version number

micha21:12:40

changes to boot.sh will be very rare, and the one you have should work for all future versions of boot

micha21:12:38

it really doesn't do much, at all

martinklepsch21:12:16

2.5.2 is in homebrew! simple_smile

martinklepsch21:12:33

@micha: curious to see what you'll make for the API docs simple_smile

micha21:12:06

i'll push the api docs in a few

flyboarder23:12:09

@micha: is there a way to suppress the warning for when checkout modifies the dependencies?

micha23:12:37

@flyboarder: which warning do you get?

flyboarder23:12:51

Warning: version conflict detected: degree9/lounge.api version changes from 0.1.0 to 0.2.0-SNAPSHOT

micha23:12:15

not sure why you'd see that warning

micha23:12:55

the checkout task is checking to make sure it's not adding any deps that are already added

micha23:12:18

that's why it does the (remove pod/dependency-loaded? ...) thing

micha23:12:26

i think you want (vec deps) there

flyboarder23:12:34

deps is always empty

micha23:12:53

oh right, nm

flyboarder23:12:17

dependencies is getting the vector passed to checkout

micha23:12:37

ah another dependnecy depends on a different version of the checkout dep

micha23:12:44

so it gets added back in

micha23:12:59

interesting

micha23:12:07

you could add :exclusions [checkout.dep/here] to all the dependencies i suppose

flyboarder23:12:57

seems excessive

micha23:12:42

that warning is telling you that it's adding the dep anyway

flyboarder23:12:22

isnt it saying that i sucessfully added the new checkout dep?

micha23:12:42

you don't want to add the new checkout dep from a jar though

flyboarder23:12:02

oh just remove the old versions

flyboarder23:12:13

ah ok i can fix that

micha23:12:13

because you have the source now in files

flyboarder23:12:23

right as files in the fileset

flyboarder23:12:39

ok makes sense

flyboarder23:12:50

so you were right i did want (vec deps) in that case

micha23:12:30

no i think you were right there

micha23:12:58

yeah you want vec deps , i think

micha23:12:24

also you can remove :dependencies from the merge-env! on the next line then

flyboarder23:12:45

yeah that works