@micha: i ran into that same problem about FileNotFoundException for 2.0.0-rc14

Suggestion to drop something in the README

@juhoteperi: how do you feel about releasing 2.5.0?

maybe this week?

@micha: Yes, I think gpg stuff is good now

https://github.com/boot-clj/boot/issues/350

I think that should be checked first

@juhoteperi: I am using derived subkeys. I can test if you need it.

@danielsz: The proposed version is in this branch: https://github.com/boot-clj/boot/tree/2.5.0-RC

@juhoteperi: OK, cool.

@onetom: Just to let you know that holygrail has been updated to the latest cljs tooling.

i was trying to do some more TDD finally but clojure.test doesn't really cut it for me. i worked with a lot of ruby/js test frameworks (cucumber*, minitest, rspec, mocha, jasmine, sinonjs) and all of them had nice assertion functions and concise, helpful messages. what's the equivalent of those in clojure which is already integrated into boot? i saw https://github.com/jaycfields/expectations/issues/52 which is promising, but no pointer to an actual boot-task 😕

we looked into midje, but only it's latest version (which is still snapshot) is actually integrated well enough with boot and it's not using pod-pools, so it a bit slow for datomic tests

im also surprised by the lack of delineation between test runners, assertion libs, test result reporters

it is true, even coming from Java

midje seems like the best choice currently

i just remembered to look around on http://www.clojure-toolbox.com/ speclj looks very much like rspec; that's something i could live with probably, if it's fast. still the question stands: which one of these are integrated with boot yet? (https://github.com/boot-clj/boot/wiki/Community-Tasks only mentions boot-test and boot-junit)

@dm3: do u have any example project which i should check it out to see how does it look like in practice and try how fast is it?

this one I saw recently: https://github.com/alexander-yakushev/compliment/tree/master/test/compliment

with lein do lein midje :autotest and try changing some code

im not interested in lein. the net is full of lein examples. we are on the boot channel for a reason 😉

but thanks if that's an example of a realistic test suite!

Is there an example of clojure deps download/inject into a running repl (from emacs if that matters) ?

(set-env! :dependencies #(conj % '[your/derp "version"]))

Off the top of my head.

This build.boot of mine can also be of interest to you - https://gitlab.com/jaen/clj-cljs-presentation/blob/master/build.boot - take a look at read-dependencies! the inital call to set-env! and update-deps task as used in dev task.

A change in the resources/dependencies.edn will result in new deps being automatically injected into the boot process.

It might not work all the time though - some deps can conflict and you have to re-run the boot process then.

@jaen: You are everywhere ^^ Thanks

Hahah. Well, if I can be of help at least... ; d

@jaen: gitlab? how is it? just trying out or planning to migrate from github or bitbucket?

In terms of bang for the buck so to speak it's the best - you get unlimited private repositories with unlimited amount of collaborators for free. AFAIR bitbucket has unlimited number of private repositories, but the amount of contributors is limited to 5 and github has no free option at all.

In terms of interface usability github is still way ahead, but between bitbucket and gitlab it's about even, maybe with a slight edge towards gitlab.

thx, i was not aware!

And the on-premise basic version is also free, I don't think either of bitbucket and github has that.

that i knew, but im not ready to maintain our own repo server just yet, though im getting more an more annoyed with the git push/pull delays... is http://gitlab.com fast for u? which country r u using it from?

(we are in hong kong, which has clogged international pipes often)

Well, when I started using gitlab it worked pretty well, recently it's a bit spotty, maybe it hit some growing pains, I guess?

I'm using it from Poland if that matters.

@juhoteperi: thanks for the heads up, i forgot about that one

ok that's it for changes to 2.5.0-RC

any feedback before release would be greatly appreciated

i created the boot-test organization on github

i was thinking that we could fork projects that use boot to this org and use them for testing new releases of boot

https://github.com/boot-test

The boot-test name could be confused with anything test-runner related

what do you recommend?

will you put a 2.5.0-RC to clojars or straight 2.5.0?

straight 2.5.0 i was thinking

but maybe a snapshot? i haven't tried that

I'm thinking making RC releases available as snapshots via clojars might be a good way to enable more people to test pre-releases w/o building themselves

not sure if I fully understand the purpose of boot-test, what kind of projects to fork did you have in mind?

i want to make sure that changes don't affect existing projects

so the idea would be to fork public projects that use boot to there

and test boot by building them and comparing results, running tests, etc

also we can use that to measure real-world performance

what do you think would be a beter name?

s/beter/better/

I'm thinking maybe we can make a single repo that clones git repos and runs boot with a specified version in them?

managing forked repos and keeping them up to date could get annoying

and then maybe we just make a boot-clj/boot-testbed repo?

I run into a dependency version number issue with encore, looking at https://github.com/ptaoussanis/encore/blob/master/DEP-CONFLICT.md

Does boot also use the order of the dependencies?

(Not sure my question makes sense - feeling a bit confused)

Trying to look at the dependency graph with boot show -p and to define the dependency version number by direct reference. But struggling a bit

@kardan: the underlying maven library, Aether, does use the order in which you specify dependencies when resolving transitive dependencies

the strategy it uses to resolve transitive dependency conflicts is it picks the "shortest path", meaning the transitive dependency that is closest to a direct dependency in the dependency graph

but if there is more than one possible resolution (i.e. multiple conflicting versions of the transitive dep with the same number of "hops") it will choose the one that comes first

does that help?

@martinklepsch: keeping forked repos up to date isn't such an important thing because what we want to test is repeatability

so testing against the same versions is what we really want

@micha: I’m chewing on your explanation, but thanks

@kardan: see this also http://stackoverflow.com/questions/7175398/maven-dependency-resolution-conflicted

and https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies

cool

Not 100% sure that I get the dependency resolution scheme. But does https://gist.github.com/kardan/6ff4cca26d6d0ac9d175 look odd? (sorry for a crappy format)

But not sure declaring a dependency first will solve my issue. The idea came from https://github.com/ptaoussanis/encore/blob/master/DEP-CONFLICT.md

that is puzzling

it says that it's using version 1.32.0

can you paste your build.boot please?

https://gist.github.com/kardan/1953fe55e14fc501f32d

that looks ok to me

i don't understand how version 1.21.0 is getting in there, as boot reports 1.32.0 is loaded

i suspect maybe a bug in the code that tests for the encore version

Ok, then at least I’m not super confused

Thanks for the help

i wonder if timbre is doing somethjing with classloaders

or something

logging in java is pretty wacky

I could not say, I don’t have a java backgound. But I’m getting there from doing Clojure

@kardan: let me know what you discover, this is a weird issue

Will do

@micha: I killed my vagrant box (where my project lives, hence the boot".sh"), now things seems to work without the specific "first in vector” declaration. Not really sure what’s going on. But in a scary way I’m glad it works now :thinking_face: But need to hit the hay now. If I run in to the problem and make progress I’ll report back. In anyway thanks for looking at my issue

@kardan: glad to hear it works, at least! thanks!