Clojurians Log v2

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

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

tenzing got me started with boot,

morning

morning

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

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

but they don't work together

oh no there it goes. I think

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.

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

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

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

@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

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

Hello All :simple_smile:

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

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

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

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

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

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

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

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

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

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

this was roughly the subject of my clojurex talk

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

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

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

@maleghast: awesome

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

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

@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

@rickmoynihan: This seems like an interesting problem

lein classpath > .lein-lockfile

that’s like 90% there 😛

of one part of the problem

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

only just occurred to me

@glenjamin: hold on… goes to try it out

you’d need to post-process it a bit

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

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

then merge over the dependencies with an appropriate lein profile

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

👏

(too much Skype)

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

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

https://skillsmatter.com/skillscasts/7251-lightning-talks-day-2

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.

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

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

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

e.g. (,1.0]

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

@glenjamin really liked your cljX talk

Good summary of the problem space

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.

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)

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 ?

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

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

i mean THIS

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

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

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)

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

haha you partly described all my woes with mranderson 😉

ha, right - i hadn't seen mranderson before

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

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

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

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

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

wohoo, i am a very accidental node coder

prefer to do it in cljs rather nowadays tbh

ha, yeah, i'm the same

mccraigmccraig: yeah, closures