Fork me on GitHub
#duct
<
2021-01-25
>
Greg Rynkowski16:01:04

Hi, are there any sample repos showing how to use Duct with deps.edn instead of Leiningen?

rickmoynihan16:01:03

None that are public that I know of… though it’s pretty straightforward. See this issue for some hints: https://github.com/duct-framework/duct/issues/92

rickmoynihan16:01:59

Simple answer is, if you’re willing to sacrifice uberjars/aot it’s easy

Greg Rynkowski16:01:32

@U06HHF230 Thanks for pointing the thread. Actually at the point where I am, I’m trying to successfully use only REPL and (integrant.repl/go). But it fails:

% clj -Mdev:repl                                                                                                                                                                                                                                                                                                                                                    nREPL server started on port 62879 on host localhost - 
[Rebel readline] Type :repl/help for online help info
user=> (dev)
:loaded
dev=> (go)
Execution error (IllegalArgumentException) at integrant.core/try-build-action (core.cljc:294).
No method in multimethod 'init-key' for dispatch value: :duct.module/logging

kwrooijen16:01:22

Looks like it can't find the duct/module.logging dependency

👍 3
rickmoynihan16:01:44

yeah or maybe ig/load-namespaces hasn’t been called?!

Greg Rynkowski16:01:37

I’m sorry, that was a silly issue, I confused duct/logger with duct/module.logging :man-facepalming: It works now

👍 3
Greg Rynkowski17:01:02

I noticed that in lein duct project template, https://github.com/duct-framework/duct/commits?author=weavejester specifed two :prep-tasks, including one for :repl. Should I provide any equivalent of that :prep-tasks for running the app in REPL?

rickmoynihan17:01:30

as far as I know the second of those is just re-establishing the default leiningen prep-tasks for the :repl profile

rickmoynihan17:01:46

though last time I looked at this was probably 2 years ago

rickmoynihan17:01:36

as far as I know also that key is only relevant if you want to manage your clojurescript compilation with duct

👍 3
rickmoynihan17:01:31

I’ve often wondered if duct uses it to aot clojure; though based upon ns dependencies… Though I’ve never seen any code in duct that did that.

rickmoynihan17:01:05

FYI: I don’t think you should use the duct machinery for clojurescript… it’s pretty outdated. You’d probably be better using shadow-cljs, or something else

rickmoynihan17:01:15

(we use shadow)

👍 3
kwrooijen17:01:27

But you could also use shadow-cljs separately from duct

rickmoynihan17:01:32

what’s the benefit to using that?

kwrooijen17:01:48

I just like having everything build in a single process. But I don't use deps.edn

rickmoynihan17:01:04

yeah ok fair enough

kwrooijen17:01:24

And you should be able to switch between Clojure / Clojurescript repls

kwrooijen17:01:31

But I haven't gotten that to work yet

rickmoynihan17:01:47

I wasn’t aware of the duct shadow module I just use shadow standalone, can switch between repls etc. but yeah it’s a separate process. I guess the interesting thing about the :duct/compiler key is that it isn’t included in the app at runtime :thinking_face:

rickmoynihan17:01:22

I could probably use that for other things in our app

kwrooijen17:01:53

Yeah I'd like to create a :duct/compiler key to compile our CSS as well

kwrooijen17:01:08

Basically have a single build system

rickmoynihan17:01:33

Not sure duct makes a good build system though… though neither does tools.deps, yet 🙂

rickmoynihan17:01:36

though simple stuff like that should work fine

kwrooijen17:01:41

How I crave a "good" build tool for clojure

rickmoynihan17:01:07

🤞 for tools.build

kwrooijen17:01:14

Would be nice

kwrooijen17:01:25

Hopefully it won't be in alpha for 3 years 😛

kwrooijen17:01:09

And I just hope it'll be more intuitive, unlike weird -A: -X: flags. But maybe that's just my preference

rickmoynihan17:01:03

tbh I find the tools.deps flags work really well… They definitely make trade offs on various things (like standardisation) in favour of fine grained control, but they’re very flexible. It’s not a build system though; and it’s not trying to be. I hear tools.build leverages the :exec-args stuff quite a bit though, so we’ll see…

rickmoynihan17:01:34

I certainly miss some bits of lein, but other aspects of tools.deps are great

kwrooijen17:01:42

I definitely like the aliases as well. But I'd much rather see (for example) clj run new ... instead of clj -X:new ... (or -A: I'm honestly not sure which one to use)

rickmoynihan18:01:02

-A is for repl invocation -X is for function eXecution -M is for Main execution Essentially -A generically provides classpath options :extra-deps and args data. -X specifies the alias that contains the :exec-fn to use (only one :exec-fn can be picked). -M similar for specifying a main namespace

rickmoynihan18:01:58

but I agree it’s a bit confusing, as stuff has changed a bit recently

Greg Rynkowski17:01:01

In the past I used to use integrant and I kinda liked config specified within clj files. With a namespaced keywords they were more readable compare to fully qualified keywords needed for edn. What is the advantage of using configs within edns vs in clj file?

kwrooijen17:01:09

For me I like the separation of code and data

👍 3
rickmoynihan18:01:00

Also if you use edn with ig/load-namespaces your require tree between components isn’t hardcoded into your app. Each component defines a subtree of requires; but the actual app is dynamically assembled out of components. Unused components aren’t loaded etc. Many configurations can be supported at once, with only the required components being loaded.