This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-23
Channels
- # announcements (5)
- # babashka (22)
- # beginners (240)
- # calva (51)
- # clj-commons (1)
- # cljsrn (9)
- # clojars (12)
- # clojure (81)
- # clojure-australia (2)
- # clojure-europe (40)
- # clojure-france (10)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-uk (37)
- # clojurescript (59)
- # clojureverse-ops (2)
- # copenhagen-clojurians (1)
- # cursive (9)
- # datomic (18)
- # emacs (12)
- # fulcro (24)
- # graalvm (48)
- # hyperfiddle (5)
- # introduce-yourself (1)
- # jackdaw (1)
- # jobs (2)
- # juxt (8)
- # lsp (25)
- # malli (8)
- # missionary (1)
- # music (3)
- # off-topic (32)
- # polylith (16)
- # quil (4)
- # re-frame (52)
- # reitit (5)
- # reveal (3)
- # rewrite-clj (26)
- # rum (1)
- # sci (1)
- # shadow-cljs (14)
- # sql (2)
- # tools-build (40)
- # tools-deps (14)
- # vrac (2)
- # xtdb (63)
I'm not sure if this is a bug in poly
but it caught me out and left me scratching my head for quite a while. In our workspace deps.edn
file we have :deps {org.clojure/clojure {:mvn/version "1.11.0-alpha2"}}
in addition to :dev
and :test
aliases and I had been assuming that poly
would use that for running tests from the development
project -- but it doesn't. I guess it uses the "default" version of Clojure for however it builds the class loader for :dev
. I hadn't noticed this until I used update-vals
in some code and the :setup-fn
started to fail for development
but not for other projects (because those have :deps {org.clojure/clojure {:mvn/version "1.11.0-alpha2"}}
in the project deps.edn
files).
If it's "not a bug", it probably deserves a note in the docs somewhere that is explicit that :deps
is ignored when running development
tests.
Thanks for reporting this. Yes, that’s how it’s implemented right now for the development
project. I makes sense to support putting things directly in :deps
, to be consistent with t.d.a
. You can create an issue if you want. I need to have a look at this, but if it’s not too much work, I will add support for this in the next version we release.
I created https://github.com/polyfy/polylith/issues/137 issue.
Thanks, Joakim!
I didn’t know :deps
alias is considered default and automatically loaded. Could you share where did you find that @U1G0HH87L? I’m asking this because you wrote “to be consistent with t.d.a
”.
Ah nevermind, you mean the main :deps
key, not an alias. Yeah, those deps should be loaded
And also paths I guess, if any.
Yes you are right, it should be both the :paths
and :deps
. I update the issue!
just wondering, is there an example anywhere of a multimethod being used as a component ? curious what the interface would look like
We have that in several components and it is not a special case. We define and implement the multimethod in the implementation (core.clj) and we have a single function that proxies to the implementation from the interface.clj.
Let’s say multimethod is foo
. It is implemented as usual. Then in interface:
(defn foo [args]
(core/foo args))
interface basically has no notion that there is a multimethod behind the scenes in core
Yes, that is correct 👍
Just looking at polylith - really like the goals. Are there any public examples of poly with both jvm (deps.edn) and shadow-cljs (browser) bases in one monorepo?
I've found this example https://github.com/DavidVujic/polylith-experiments