Fork me on GitHub
#polylith
<
2021-10-26
>
Andrés Rodríguez17:10:20

Do tests run in parallel within each brick? If not, how can I get them to do that?

tengstrand18:10:12

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.

👍 1
Andrés Rodríguez19:10:44

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.

tengstrand19:10:35

Thanks. Looks good to me!

emccue19:10:37

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 "...."}}}

seancorfield20:10:59

Why not just use :override-deps (or perhaps :default-deps) in the workspace and/or project deps.edn files to provide global versions?

emccue21:10:17

I don’t really understand those two options, but this feels more explicit i guess?

emccue21:10:50

also with those don’t you make {some.lib/thing {}}? Like, its invalid deps.edn unless you propagate some profile down?

seancorfield21:10:04

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.

seancorfield21:10:47

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).

seancorfield21:10:40

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.

seancorfield21:10:20

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 🙂

emccue21:10:25

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"}}

emccue21:10:01

“fully normalized dependencies”

emccue21:10:29

so for libraries you are able to have a single version for, libraries/thing

emccue21:10:54

for libraries you need to maintain multiple libraries/thing-a.b.c and libraries/thing-d.e.f

emccue21:10:08

that naming scheme would fall apart with git shas, but 🤷

emccue21:10:01

i’d imagine antq could figure this out - poly not so much

seancorfield21:10:07

I personally think that is much worse than the problem you're trying to solve...

emccue21:10:24

which part?

seancorfield21:10:02

The whole approach.

seancorfield21:10:52

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! 🙂