Fork me on GitHub
#clojure
<
2021-01-02
>
Timofey Sitnikov11:01:31

Good morning Clojurians, have a question, if I had aliases with the same name in the global and project deps.edn, do the extra-deps get merged or replaced? For example: ~/.clojure/deps.edn:

{:deps {org.clojure/clojure {:mvn/version "1.10.1"}}
         :aliases {:dev {:extra-deps iced-nrepl/iced-nrepl {:mvn/version "1.1.1"}}}}
~/clojure/my_app/deps.edn
{:deps {org.clojure/clojure {:mvn/version "1.10.1"}}
         :aliases {:dev {:extra-deps com.wsscode/pathom {:mvn/version "2.3.0-alpha17"}}}}
When running clj -A:dev, should clj merge, meaning include both the com.wsscode/pathom and iced-nrepl/iced-nrepl or should clj only use the extra-deps: map in the project folder, meaning it would not include the iced-nrepl/iced-nrepl? In my system it does not merge, but replaces with the project deps.edn, wonder if my system is not setup correctly to source global deps.edn.

dharrigan11:01:35

My understanding that the project level is more specific, so it will replace the "root" level.

Timofey Sitnikov12:01:54

Ok, that makes sense. Wish there was a way to merge, or globally include deps for :dev alias.

dharrigan12:01:18

I believe these things (and more!) are being discussed in #tools-deps 🙂

dharrigan12:01:48

Things akin to merging etc...you can always ask there if you want to query something 🙂

Timofey Sitnikov12:01:13

@UEQPKG7HQ, thats interesting, I did not know about tools.deps.alpha. I am assuming that it will be part of the clojure once it is released?

pavlosmelissinos12:01:21

You're already using it, it's what drives deps.edn files 😉

pavlosmelissinos12:01:41

Not sure if it's a recommended approach but, as a workaround, you might be able to "simulate" the behaviour you want by using qualified keywords as alias names, e.g. https://github.com/practicalli/clojure-deps-edn/blob/65a48e1547d289a3d647d9f32bf3d2cc7fe8d5d3/deps.edn#L117 uses :env/dev In which case you could load the equivalent of clj -M:env/dev:dev in your REPL and have the dependencies of both aliases (I haven't tested it but I think it should work)

👍 1
Timofey Sitnikov13:01:40

I agree, it would work, but the challenge is with shadow-cljs. Although there may be command line arguments that I can use when starting shadow-cljs.

seancorfield18:01:32

I really should rename some of the aliases in my dot-clojure deps.edn file so they don't collide with common names used in projects. @U05254DQM’s approach is better there since he uses qualified alias names in his dot-clojure deps.edn file so they are less likely to collide. :dev is probably my worst offender.

practicalli-john18:01:30

As mentioned, I use :env/dev and :env/test for the user wide alias. I find qualified aliases also provide more context, so it's easier to remember what the alias does.

seancorfield18:01:36

I just updated my dot-clojure file to have :dev/repl to avoid conflicts (`:dev` still exists and is the same code, because it'll take a while for my muscle memory to catch up!).

seancorfield18:01:22

(and my :dev/repl alias now works with Figwheel Main and can be used in combination with Reveal!)

Timofey Sitnikov19:01:23

@U04V70XH6, do you use Figwheel? What about shadow-cljs?

seancorfield19:01:30

I have used Shadow a bit, when I was hacking on Chlorine (the Clojure package for Atom). I'm very allergic to JavaScript so I want something less node-adjacent than Shadow.

seancorfield19:01:11

This week I started using Figwheel and I really like it. And re-frame.

Timofey Sitnikov19:01:30

It seems like shadow-cljs is closer to deps.edn, I thought it was simpler? But I do see what you mean, most of figwheel is in clojure.

seancorfield20:01:47

Although shadow-cljs can be used as a Java library, that's not the primary supported approach and folks are just like "Embrace Node.js! It's fine that Shadow uses npx/npm!" but I really don't want to go into the JS swamp if I can avoid it and Figwheel seems to keep me further away from that swamp 🙂

p-himik20:01:14

FWIW going with shadow-cljs does not mean that you have to use NPM in your projects. It just means that you can use NPM to install shadow-cljs itself, that's it.

seancorfield20:01:54

@U2FRKM4TW It means I have to have node etc installed -- which I don't want.

seancorfield20:01:19

I don't know how much more clearly I can say "I do not want node.js on my machine!" 🙂

Timofey Sitnikov20:01:31

Well, I chose shadow-cljs, because it was so active and popular (not the best way to make a choice) but looking at figwheel, it is a bit newer (first commit in April, 2018) and it looks like Shadow first commit was in October 2015!

Timofey Sitnikov20:01:15

Figwheel commits are more Clojure like, it seems more stable.

p-himik20:01:41

@U04V70XH6 It wasn't an attempt to persuade you - it was an attempt to convey to others that Node won't "pollute" your projects (your statements above can be read as implying the opposite).

seancorfield20:01:41

@U2FRKM4TW Fair enough. Every time I mention anywhere that I'm using Figwheel, everyone immediately suggests Shadow and then seems to want me to justify why I'm not using Shadow. It's a bit annoying.

Timofey Sitnikov20:01:12

@U04V70XH6 did you notice reduction in start up time?

seancorfield20:01:45

Start up time of what?

Timofey Sitnikov20:01:19

For figwheel to startup. For shadow, from the time I type in shadow-cljs watch main to the time it all compiles it takes about a minute. When I am exploring projects, waiting a minute is annoying, I wish it was faster.

p-himik20:01:01

@U012GN57FJ9 Just in case, if you switch between the projects often, you can use the server mode to reduce the startup time: https://shadow-cljs.github.io/docs/UsersGuide.html#_server_mode

seancorfield20:01:21

@U012GN57FJ9 I tend to start a REPL and leave it running for days (or even weeks) so the startup time of the REPL doesn't matter to me. I've had clojure -M:reveal:fig:build:dev (a combination of the Figwheel aliases and my own dot-clojure stuff) running since Tuesday on my laptop 🙂

practicalli-john20:01:31

Figwheel-main works for me, its simple to use and I dont need the features or added complexity of shadow-cljs, especially configuring the projects. Figwheel-main has a nice template to get started and as Sean mentioned, startup time is almost irrelevant during development. Figwheel-main recently added bundles for npm packages, so I'd probably look at that first before changing to shadow-cljs. Nothing wrong with shadow-cljs, its just not what I am familar with and I dont see the need to adopt it as yet. I might try shadow-cljs one day, but dont have any motivation to do so soon. Much more likely to spend time learning re-frame a bit more, as I have tooling that works already.

Timofey Sitnikov21:01:18

@U04V70XH6, Understand, that makes sense.

Timofey Sitnikov21:01:36

@U05254DQM, the words simpler resonate with me, I am a neovim/tmux/terminal type of a guy, love to keep things simple and minimize the abstraction layers. I will have to give figwheel a try.

GGfpc20:01:53

Has anyone used travisCI with with the clojure command line tools instead of leiningen? It keeps trying to run lein deps on my builds

seancorfield20:01:37

@ggfpc12495 Any reason to use TravisCI rather than CircleCI?

GGfpc20:01:48

I just use it because it's really easy to configure with github, would you recommend switching?

GGfpc20:01:12

And it's free for private repos for students, at least it was when I first started

seancorfield20:01:19

CircleCI is much more Clojure-friendly (the company uses Clojure). Don't know about the private repo integration tho'. There's also GitHub Actions -- which is what most of my project use now...

GGfpc20:01:59

I'll take a look, thanks!