Fork me on GitHub
#ldnclj
<
2016-01-26
>
malcolmsparks01:01:53

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

malcolmsparks01:01:26

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

malcolmsparks01:01:03

tenzing got me started with boot,

xlevus10:01:28

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

xlevus10:01:51

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

xlevus10:01:04

but they don't work together

xlevus11:01:29

oh no there it goes. I think

rickmoynihan11:01:06

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.

rickmoynihan11:01:25

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

martinklepsch11:01:39

@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 :)

rickmoynihan11:01:52

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

rickmoynihan11:01:01

@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

rickmoynihan11:01:03

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

martinklepsch11:01:36

@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 ;)

maleghast11:01:39

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

martinklepsch11:01:13

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

rickmoynihan11:01:54

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

rickmoynihan11:01:32

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

martinklepsch11:01:45

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

glenjamin11:01:11

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

rickmoynihan11:01:51

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

rickmoynihan11:01:47

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

maleghast11:01:06

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

glenjamin11:01:56

this was roughly the subject of my clojurex talk

rickmoynihan11:01:42

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

rickmoynihan11:01:30

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

maleghast11:01:41

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

rickmoynihan11:01:44

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

rickmoynihan11:01:33

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

maleghast11:01:45

@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

maleghast11:01:02

@rickmoynihan: This seems like an interesting problem

glenjamin11:01:05

lein classpath > .lein-lockfile

glenjamin11:01:12

that’s like 90% there 😛

glenjamin11:01:25

of one part of the problem

rickmoynihan11:01:39

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

glenjamin11:01:45

only just occurred to me

maleghast11:01:51

@glenjamin: hold on… goes to try it out

glenjamin11:01:01

you’d need to post-process it a bit

glenjamin11:01:21

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

rickmoynihan11:01:27

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

rickmoynihan11:01:09

then merge over the dependencies with an appropriate lein profile

maleghast11:01:22

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

maleghast11:01:09

(too much Skype)

martinklepsch12:01:35

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

martinklepsch12:01:02

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

martinklepsch12:01:01

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.

rickmoynihan12:01:02

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

martinklepsch12:01:41

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

rickmoynihan12:01:25

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

rickmoynihan13:01:42

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

benedek13:01:53

@glenjamin really liked your cljX talk

benedek13:01:11

Good summary of the problem space

agile_geek15:01:24

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.

benedek18:01:47

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)

mccraigmccraig18:01:44

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 ?

benedek19:01:51

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

benedek19:01:13

i mean THIS

benedek19:01:30

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

mccraigmccraig19:01:39

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

mccraigmccraig19:01:30

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)

mccraigmccraig19:01:16

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

benedek19:01:39

haha you partly described all my woes with mranderson 😉

mccraigmccraig19:01:32

ha, right - i hadn't seen mranderson before

benedek19:01:50

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

mccraigmccraig19:01:16

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

benedek19:01:18

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

benedek19:01:43

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

mccraigmccraig19:01:11

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

benedek19:01:12

wohoo, i am a very accidental node coder

benedek19:01:22

prefer to do it in cljs rather nowadays tbh

mccraigmccraig19:01:16

ha, yeah, i'm the same

glenjamin23:01:29

mccraigmccraig: yeah, closures