This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-25
Channels
- # announcements (6)
- # babashka (53)
- # beginners (199)
- # calva (101)
- # cider (8)
- # clara (17)
- # cljs-dev (1)
- # clojure (86)
- # clojure-australia (1)
- # clojure-dev (33)
- # clojure-europe (29)
- # clojure-france (13)
- # clojure-nl (6)
- # clojure-norway (7)
- # clojure-poland (3)
- # clojure-spec (2)
- # clojure-uk (9)
- # clojurescript (18)
- # community-development (2)
- # cursive (2)
- # datomic (8)
- # duct (43)
- # emacs (9)
- # events (6)
- # figwheel-main (1)
- # fulcro (7)
- # integrant (1)
- # jobs (1)
- # jobs-rus (1)
- # lambdaisland (1)
- # malli (19)
- # nrepl (2)
- # off-topic (31)
- # pathom (35)
- # quil (1)
- # reagent (4)
- # remote-jobs (7)
- # schema (1)
- # shadow-cljs (58)
- # spacemacs (6)
- # startup-in-a-month (12)
- # tools-deps (10)
- # xtdb (40)
Hi, are there any sample repos showing how to use Duct with deps.edn instead of Leiningen?
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
Simple answer is, if you’re willing to sacrifice uberjars/aot it’s easy
@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
yeah or maybe ig/load-namespaces
hasn’t been called?!
I’m sorry, that was a silly issue, I confused duct/logger with duct/module.logging :man-facepalming: It works now
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?
as far as I know the second of those is just re-establishing the default leiningen prep-tasks for the :repl
profile
though last time I looked at this was probably 2 years ago
as far as I know also that key is only relevant if you want to manage your clojurescript compilation with duct
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.
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
what’s the benefit to using that?
yeah ok fair enough
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:
I could probably use that for other things in our app
Not sure duct makes a good build system though… though neither does tools.deps, yet 🙂
though simple stuff like that should work fine
yeah same
🤞 for tools.build
And I just hope it'll be more intuitive, unlike weird -A:
-X:
flags. But maybe that's just my preference
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…
I certainly miss some bits of lein, but other aspects of tools.deps are great
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)
-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
but I agree it’s a bit confusing, as stuff has changed a bit recently
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?
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.