ldnclj

Find us on #clojure-uk
malcolmsparks 2016-01-26T01:53:53.000025Z

+1 - boot is awesome - I'm using it on my training courses

malcolmsparks 2016-01-26T01:55:26.000026Z

for cljs, definitely boot - setup is simpler, more flexible, feature parity with figwheel (actually I would say it's more robust now than figwheel)

malcolmsparks 2016-01-26T01:56:03.000027Z

tenzing got me started with boot,

thomas 2016-01-26T09:01:09.000028Z

morning

lee-jon 2016-01-26T09:34:33.000029Z

morning

xlevus 2016-01-26T10:51:28.000030Z

gg me. Started a project 2 months ago. Can't for the life of me how to run it _

xlevus 2016-01-26T10:51:51.000031Z

lein run-dev works. and lein figwheel runs /something/

xlevus 2016-01-26T10:52:04.000033Z

but they don't work together

xlevus 2016-01-26T11:00:29.000034Z

oh no there it goes. I think

2016-01-26T11:16:06.000035Z

What do people see the advantages of boot are for pure clojure development? From the little I've seen of boot my issue in adopting it is that it doesn't really seem to fix any problems I have with leiningen... My main problem with lein is in managing multi-project builds and ensuring they're repeatable. We have dozens of projects some open, some proprietary with dependencies between them and I always find that there's a tension between using SNAPSHOTs which are great for dev and integrating but poor for repeatability and version-locking everything which is great for repeatability but rubbish for CI & dev. From what I've seen boot doesn't really solve this problem - though I'm sure you could solve it with a boot script, I'd ideally like each project/repo to be independently buildable too.

2016-01-26T11:17:25.000036Z

I've not yet found a solution to this problem that I'm happy with - though lein-voom looks closest to what I need - I ran into some issues when trying to use it. My hope for boot was that it would address it - but sadly it doesn't seem to... I guess the problem is that both boot and lein inherit this issue from maven

martinklepsch 2016-01-26T11:18:39.000037Z

@rickmoynihan: I'd suggest opening an issue on the boot repo describing your problem and pointing to some existing solutions. Because of boots flexibility there will be a way to solve these things I guess :)

2016-01-26T11:20:52.000038Z

lein-ancient definitely helps make this manageable - as you can just do it manually - but again locking stops your CI integrating... You could also setup your CI to run lein ancient - then test, then push when things pass - but I don't really like having the CI create commits as handling merges etc becomes a pain

2016-01-26T11:22:01.000039Z

@martinklepsch: I might consider that -- when I first took a look at boot (probably about 6 months ago) I spoke to the devs in #C053K90BR and asked if boot solved this - and they said it didn't

2016-01-26T11:23:03.000040Z

I just wish that lein or boot had a defacto/default way of handling this issue

maleghast 2016-01-26T11:23:11.000041Z

Hello All :simple_smile:

martinklepsch 2016-01-26T11:23:36.000042Z

@rickmoynihan: the answer if boot solves this will still be no. Boot is a tool to program your build so you'll have to think about your specific problem and how to solve it on your own ;)

maleghast 2016-01-26T11:23:39.000043Z

I was just (finally) giving cljs a go and I realised that I’d not poked my head in here for ages...

martinklepsch 2016-01-26T11:24:13.000044Z

Part of that thinking can be aided by other people replying to your issue and giving suggestions/ideas

2016-01-26T11:24:54.000045Z

@martinklepsch: sure I get that - in which case having a pattern / plugin to solve it would be useful

2016-01-26T11:26:32.000046Z

I've raised this issue a couple of times, including on the clojure mailing list - and the responses have so far been unfruitful - I guess most people don't see it as a problem

martinklepsch 2016-01-26T11:26:45.000047Z

@rickmoynihan: it's up to the people with these problems to write such plugin :)

glenjamin 2016-01-26T11:28:11.000048Z

the best version approach i’ve seen in general dev ecosystems is imo: depend on version-ranges, use a lockfile in applications

2016-01-26T11:29:51.000049Z

@martinklepsch: agreed - and I have in small ways... https://github.com/RickMoynihan/lein-build-env but its a bigger problem

2016-01-26T11:30:47.000051Z

@glenjamin: yes I think lockfiles are a big part of the solution

maleghast 2016-01-26T11:31:06.000052Z

I tell you what @rickmoynihan, if you decide to have a crack at writing something to “fix” this problem I’d love to help out / contribute. This is an area that I need to learn more about anyway - build cycles, artifacts etc., and I have to be honest all the Clojure I’ve done up to now has not been “big enough”, but I would like to think that one day it will be...

glenjamin 2016-01-26T11:31:56.000053Z

this was roughly the subject of my clojurex talk

👍 1
2016-01-26T11:34:42.000054Z

@maleghast: I'd certainly like to crack it, but there are many other things I need to crack first... I think lein-voom tries to solve this problem and it might actually do it... Unfortunately it seems to be relatively unmaintained... with numerous outstanding bugs and PRs unmerged etc... Most recent changes seem to just be version bumps... And like I said I ran into some problems when I tried to use it, that I couldn't figure out how to get around. https://github.com/LonoCloud/lein-voom/

2016-01-26T11:35:30.000057Z

But maybe I didn't try hard enough - when I find time I'll look into it some more

maleghast 2016-01-26T11:35:41.000058Z

@rickmoynihan: I’ll go and have a poke around - if I get anywhere I’ll try to let you know...

2016-01-26T11:35:59.000059Z

@maleghast: awesome

2016-01-26T11:36:44.000060Z

@maleghast: I'm happy to discuss it with you

2016-01-26T11:37:33.000061Z

I think most of the pieces are probably out there already - e.g. lein-ancient -- it might just be a case of rolling a few plugins together

maleghast 2016-01-26T11:37:45.000062Z

@rickmoynihan: Sounds good. I’ve been thinking for a while that I need to get back to contributing to OSS a bit more properly than just using it anyway - I did contribute years ago, but then allowed myself to think that life got in the way

maleghast 2016-01-26T11:38:02.000063Z

@rickmoynihan: This seems like an interesting problem

glenjamin 2016-01-26T11:38:05.000064Z

lein classpath > .lein-lockfile

glenjamin 2016-01-26T11:38:12.000065Z

that’s like 90% there 😛

glenjamin 2016-01-26T11:38:25.000066Z

of one part of the problem

2016-01-26T11:38:39.000067Z

@glenjamin: hmmm I can't believe I didn't think of that

glenjamin 2016-01-26T11:38:45.000069Z

only just occurred to me

maleghast 2016-01-26T11:38:51.000070Z

@glenjamin: hold on… goes to try it out

glenjamin 2016-01-26T11:39:01.000071Z

you’d need to post-process it a bit

glenjamin 2016-01-26T11:39:21.000072Z

but it should contain fully qualified jar names and versions of every dependency

2016-01-26T11:39:27.000073Z

obvs would need to remove the paths... and probably convert that back into a :dependencies format

2016-01-26T11:40:09.000075Z

then merge over the dependencies with an appropriate lein profile

maleghast 2016-01-26T11:40:22.000076Z

Yep, that looks like it would be a very good place to start actually

maleghast 2016-01-26T11:40:31.000077Z

👏

maleghast 2016-01-26T11:41:09.000079Z

(too much Skype)

martinklepsch 2016-01-26T12:37:35.000080Z

wouldn't it also be pretty simple to provide a vector of artifacts + version ranges and find the most recent in the given range?

martinklepsch 2016-01-26T12:38:02.000081Z

@glenjamin: do you have a link to your ClojureX talk?

martinklepsch 2016-01-26T12:42:01.000084Z

admittedly looking up fitting versions will be a build time thing so whenever this thing gets into clojars the version will be fixed again. might be good enough for applications and the problem @rickmoynihan described before.

2016-01-26T12:56:02.000085Z

@martinklepsch: does lein not already do that? e.g. lein deps already fits versions... and lein release / lein deploy normally force you to lock your versions before publication (though admittedly you can force it)

martinklepsch 2016-01-26T12:56:41.000086Z

@rickmoynihan: dunno, how would you specify a range with Lein?

2016-01-26T12:57:25.000087Z

well -SNAPSHOT is technically a range... and I think you can also use maven ranges

2016-01-26T12:58:13.000089Z

e.g. (,1.0]

2016-01-26T13:03:42.000090Z

TBH my main problems are probably more to do with building stable releases on build servers - than creating stable releases... e.g. my jenkins project A depends on project B... So if I push a commit to project B I'd like jenkins to build it and test it and then test project A against it too... only if project A's tests pass do I want project B to be considered success.... Unfortunately for A to see the latest B, you have to lein install project B - before you've fully QA'd it (i.e. run project A's tests with it set as a dependency).... This can then pollute the local .m2 cache with broken builds of project B

benedek 2016-01-26T13:17:53.000093Z

@glenjamin really liked your cljX talk

benedek 2016-01-26T13:18:11.000094Z

Good summary of the problem space

🦜 2
agile_geek 2016-01-26T15:56:24.000097Z

Of course I'll take credit for having helped select @glenjamin's #C075TNSSC talk....and the blame for forcing it to be only 10-12 mins! I think it was one of the lightning talks that could have benefited with a 20 min slot.

benedek 2016-01-26T18:11:47.000098Z

it definitely is a very interesting topic. i mean dependencies possibly the most horrible thing in programming really (not even frightened to be that generic)

mccraigmccraig 2016-01-26T18:46:44.000099Z

i've had plenty of gruesome jvm & rb dependency hell experiences... anyone got any horror stories to tell about the node approach, or is it genuinely better ?

benedek 2016-01-26T19:03:51.000100Z

hm.. that is tricky question. I think it is an other kind of hell 😉

benedek 2016-01-26T19:05:09.000101Z

this https://docs.npmjs.com/how-npm-works/npm3-dupe

benedek 2016-01-26T19:05:13.000103Z

i mean THIS

benedek 2016-01-26T19:08:30.000104Z

meanwhile i would like to see a local, nested dependency graph at least as an option for clj as well

mccraigmccraig 2016-01-26T19:16:39.000105Z

maybe - duplication would seem to be a nicer sort of hell, perhaps with sunloungers and free cocktails, than completely irreconcilable deps, but maybe i'm missing something

mccraigmccraig 2016-01-26T19:17:30.000106Z

presumably a nested dep graph would be a major clojure change - it would break pre-compilation (since nested deps would require re-compilation to munge generated classnames)

mccraigmccraig 2016-01-26T19:18:16.000107Z

and if any deps go out to javaland anywhere then it's time to pray

benedek 2016-01-26T19:18:39.000108Z

haha you partly described all my woes with mranderson 😉

mccraigmccraig 2016-01-26T19:19:32.000109Z

ha, right - i hadn't seen mranderson before

benedek 2016-01-26T19:19:50.000110Z

although i dealt with java deps with renaming them as well 😜

mccraigmccraig 2016-01-26T19:20:16.000111Z

yeah, i guess there is a long and venerable tradition of doing that to java deps

😆 1
benedek 2016-01-26T19:20:18.000112Z

a possible way to take with generated classnames too perhaps?! not sure...

benedek 2016-01-26T19:20:43.000113Z

indeed… I guess clojure just inherited a type of dependency hell from the java/jvm world

mccraigmccraig 2016-01-26T19:22:11.000114Z

am i right in thinking that node's packages have all their implementations hidden in closures ?

benedek 2016-01-26T19:26:12.000116Z

wohoo, i am a very accidental node coder

benedek 2016-01-26T19:26:22.000117Z

prefer to do it in cljs rather nowadays tbh

👍 1
mccraigmccraig 2016-01-26T19:31:16.000118Z

ha, yeah, i'm the same

glenjamin 2016-01-26T23:23:29.000119Z

mccraigmccraig: yeah, closures