Clojurians Log v2

Not a huge fan, but I do want to pick the most practical approach, so let's think about this for a moment. The plan at the moment is to not have Ghostwheel in your main dependencies, because then :override-deps doesn't work as you pointed out, but rather have both the core version and the stubs artifact in your :extra-deps in your respective dev and prod profiles.

right, because it it is a cljc file, and I need to be able to select which I’m using when I run a dev vs prod build with shadow-cljs. Don’t really care too much on the clj side if it isn’t stubs, because they disable by default.

and shadow doesn’t have a way to select which deps for prod or dev because the assumption there is that prod is a post-step and deps don’t matter

Ah, this rings a bell. I believe I had a conversation with Thomas about the stubs thing a few months ago and he didn't like it. So just to confirm, am I understanding / remembering correctly that with Shadow there is no way to do the separate :extra-deps setup that I have in mind but that :override-deps would work, so a stub version of the main artifact would sort it out?

Let me retry the cases…my brain is failing to remember what I was thinking 4 days ago

but the crux, yes, is that :override-deps won’t work if the artifacts have diff names. Thomas is a smart guy, so if he had suggestions they’re probably better than mine 🙂

I have to publish Fulcro referring to one or the other or it won’t compile for ppl, and pushing non-stubs ghostwheel to unsuspecting users might cause them misery.

so I have to publish with stubs…but I guess they could use exclusions…but then if it comes in from lots of places, that’s a lot of exclusions

which means they possibly (and easily) end up with both stubs and non-stubs

which is quite ugly

Another option is to leverage the JVM option more to toggle the macros into various states, with the default being stubs.

and when I think about it again: the biggest deal was gw/>def, not the stubs lib: since the macros already stub themselves out, don’t they? So, if >def was being used in your lib and mine, and no -Dghostwheel.enabled was there, then everything could just stub, and DCE will get rid of unused functions.

so, revisiting it: I don’t think we need the stubs lib now that we have gw/>def…I think that solves most of the issue (assuming you use it on your own specs)

and unless you’re supporting bootstrapped cljs, the macros themselves need to be in :clj clauses for minimal size I think.

Problem is that a lot of people use simple rather than advanced compilation in production and even with advanced compilation, DCE has been occasionally unreliable in the past. And with the additional dependencies the main artifact pulls in, I much prefer to do this with stubs—there's much less that can go wrong there. I see your problem now though and I'm pretty much sold on your previous suggestion, that is to make the stubs a version rather than a separate artifact. That being said, you can still have Ghostwheel disabled and rely on DCE instead, but I probably won't recommend it in the docs.

Can you think of any issues with adding random suffixes to an artifact version? I've only seen/used -SNAPSHOT in the past and I don't know if that's just a special case or if any random suffix is supported with no issues.

Apparently any qualifier is possible and generally considered to be an older version than the qualifier-less one, which is perfect.