This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-26
Channels
- # announcements (28)
- # asami (13)
- # babashka (10)
- # beginners (170)
- # boot (1)
- # calva (35)
- # cider (21)
- # circleci (13)
- # clara (6)
- # clj-http (1)
- # clj-kondo (29)
- # cljdoc (5)
- # clojure (89)
- # clojure-czech (2)
- # clojure-europe (20)
- # clojure-france (16)
- # clojure-nl (6)
- # clojure-uk (5)
- # clojurescript (80)
- # community-development (6)
- # conjure (13)
- # cursive (18)
- # datascript (9)
- # datomic (1)
- # duct (1)
- # gratitude (2)
- # helix (7)
- # jobs (2)
- # kaocha (3)
- # lsp (22)
- # malli (5)
- # meander (1)
- # other-languages (34)
- # pathom (18)
- # polylith (24)
- # quil (10)
- # re-frame (5)
- # releases (1)
- # remote-jobs (4)
- # reveal (7)
- # shadow-cljs (8)
- # tools-deps (53)
Do tests run in parallel within each brick? If not, how can I get them to do that?
The current test runner executes the tests sequentially and doesn’t support executing them in parallell. You could create an issue if you want, and I can have a look at it.
Posted! https://github.com/polyfy/polylith/issues/153 Please let me know if I should clear up any particular section, I've tried to be as specific as possible but english is not my first language.
Thanks. Looks good to me!
maybe heavy handed, but what if instead of duplicating dependency versions we have a libraries/
folder that just has deps.edn files with versions declared
like
libraries/
ring/
deps.edn
bases/
my_base_1/
deps.edn
my_base_2/
deps.edn
where the first one just contains
{:deps {ring/ring-core {:mvn/version "1.9.4"}
ring/ring-servlet {:mvn/version "1.9.4"}
ring/ring-jetty-adapter {:mvn/version "1.9.4"}}}
and then the next two
{:deps {libraries/ring {:local/root "../../libraries/ring"}}}
{:deps {libraries/ring {:local/root "../../libraries/ring"}}
some.base {:local/root "...."}}}
Why not just use :override-deps
(or perhaps :default-deps
) in the workspace and/or project deps.edn
files to provide global versions?
also with those don’t you make {some.lib/thing {}}
? Like, its invalid deps.edn unless you propagate some profile down?
You can provide a valid coordinate. :override-deps
will just, well, override it. But mostly we write {}
since we never use the deps.edn
file in a context where :override-deps
is not propagated.
If you read my deps.edn
/monolith blog series, you'll see we used to rely on :override-deps
a lot. But we decided the explicit duplication with versions was clearer -- so we could immediately see which version a given subproject was declaring -- and Polylith allows you to override that in projects
anyway (including the "development" project under the :dev
alias in the workspace deps.edn
file).
Plus the poly libs
tool tells you about any versions that are out of sync (which you may actually want). And we use antq
to check all our deps.edn
files for the latest versions of libraries on a regular basis.
But there are lots of ways to "solve" this problem. I like ours. I don't like yours. But you may well not like ours 🙂
i’m just playing around with it right now, but i’m kinda liking this
:deps {libraries/clojure {:local/root "libraries/clojure"}
libraries/hiccup {:local/root "libraries/hiccup"}
libraries/ring {:local/root "libraries/ring"}
libraries/discord4j {:local/root "libraries/discord4j"}
libraries/data-xml {:local/root "libraries/data-xml"}}
for libraries you need to maintain multiple libraries/thing-a.b.c
and libraries/thing-d.e.f
I personally think that is much worse than the problem you're trying to solve...
The whole approach.
As I said, we've tried a few approaches and we liked :override-deps
(because that's built-in and is a standard, predictable, documented way to pin versions 🙂 ) but in the end, we preferred the simple, explicit option, even though it introduced some duplication. But, hey, be creative! 🙂