polylith 2023-07-07 | Slack Archive

Kent Bull00:07:25

What is the proper way to make a new Java library accessible from the REPL of a poly project using Cursive? I’ve got a base project called rest-api and I have added some Java libraries, specifically a lorem ipsum library, com.thedeanda.lorem. I’m importing as so:

(:import [com.thedeanda.lorem LoremIpsum])

When I try to evaluate my namespace form in the REPL then I get classloader problems. This happens with other dependencies as well. Do I need to add other aliases to my “Clojure Deps Projects” config?

Kent Bull00:07:19

Maybe this is a cursive question

Kent Bull00:07:25

Updating to the EAP of IntelliJ and Cursive solved my problems as long as I updated my root level deps.edn to use :extra-deps as follows:

:aliases  {:dev {:extra-paths ["development/src"]
                  :extra-deps {poly/user {:local/root "components/user"}}

per component

🎉 2

💯 2

Kent Bull00:07:33

REPL works perfectly now.

Kent Bull00:07:32

It’s cool the Cursive team added direct support for Polylith. This was right in time for what I wanted to do!

Kent Bull00:07:38

@U04V70XH6 updating the guide in the https://polylith.gitbook.io/poly/architecture/component section towards the end with a note about how this works now in Cursive would be helpful to the next person who comes along:

Kent Bull00:07:21

My root level deps.edn now looks like the following:

{:aliases  {:dev {:extra-paths ["."
                                "development/src"
                                ]
                  :extra-deps {poly/user {:local/root "components/user"}
                               poly/credentials {:local/root "components/credentials"}
                               poly/cli {:local/root "bases/cli"}
                               poly/rest-api {:local/root "bases/rest-api"}
                               org.clojure/clojure {:mvn/version "1.11.1"}
                               org.clojure/tools.deps {:mvn/version "0.18.1354"}
                               io.github.seancorfield/build-clj {:git/tag "v0.9.2" :git/sha "9c9f078602effe4df2b7b505003596ea1c5de436"}}}

            :test {:extra-paths ["components/user/test"
                                 "components/credentials/test"
                                 "bases/rest-api/test"
                                 "bases/cli/test"]}

            ; Sean says you should learn to use tools.deps. He deprecated this project because it has too many
            ; knobs and options
            :build {:deps {io.github.seancorfield/build-clj {:git/tag "v0.9.2" :git/sha "9c9f078602effe4df2b7b505003596ea1c5de436"}}
                    :paths ["build/resources"]
                    :ns-default build}

            :poly {:main-opts ["-m" "polylith.clj.core.poly-cli.core"]
                   :extra-deps {polyfy/polylith
                                {:git/url   ""
                                 :sha       "1209a81e6b8f70987050d65d106e99d1a902969a"
                                 :deps/root "projects/poly"}}}}}

Kent Bull00:07:50

And the bases/rest-api/deps.edn looks like so:

{:paths ["src" "resources"]
 :deps {ring/ring-core {:mvn/version "1.10.0"}
        ring/ring-jetty-adapter {:mvn/version "1.10.0"}
        integrant/integrant {:mvn/version "0.8.0"}
        environ/environ {:mvn/version "1.2.0"}
        metosin/reitit {:mvn/version "0.5.5"}
        seancorfield/next.jdbc {:mvn/version "1.1.582"}
        org.postgresql/postgresql {:mvn/version "42.2.14"}
        clj-http/clj-http {:mvn/version "3.10.0"}
        ovotech/ring-jwt {:mvn/version "1.3.0"}
        camel-snake-kebab/camel-snake-kebab {:mvn/version "0.4.1"}
        com.github.f4b6a3/ulid-creator {:mvn/version "5.2.0"}
        com.thedeanda/lorem {:mvn/version "2.1"}}
 :aliases {:test {:extra-paths ["test"
                                "development/src"]
                  :extra-deps {}}}}

Kent Bull00:07:22

I’d be happy to contribute a Polylith book update if I was pointed in the right direction. If this is enough for you then that’s good, too.

Kent Bull00:07:04

A section in the Polylith docs to show how and where to add dependencies would be nice. It is straightforward to guess, though it would be nice to have a walkthrough.

seancorfield01:07:58

You probably don't need/want these in the :dev alias: org.clojure/tools.deps, io.github.seancorfield/build-clj

seancorfield01:07:16

(although maybe Cursive needs those for you to be able to edit build.clj?)

seancorfield01:07:49

I would recommend uses a REPL with :dev:build if you want to work on build.clj and leaving the tools/build stuff out of :dev.

cfleming01:07:03

Cursive doesn’t need that, I agree that having a separate build alias is better.

👍 2

tengstrand03:07:55

Thanks for pointing out this. Wil fix this and include it in the next release that I’m working on.

Kent Bull01:07:09

yes, @U04V70XH6, I was able to take org.clojure/tools.deps, io.github.seancorfield/build-clj out of my :dev alias and was still able to build just fine.

Chris Lester00:07:06

Question on the intersection of polylith components and spec.. I've adopted a pattern that is essentially a conforming passthru for all interface functions that calls conform against a given spec on each of a functions arguments .. so I can be sure that the data inside a component is what we're expecting. I didn't think about s/assert however, which does a similar thing (at dev time) but compiles out .. so provides some significant % of the same benefit for development. Are there arguments for using s/conform for these boundaries over s/assert? A couple I can think of for s/conform is that you get only the data you spec'd (so you know what is in the map, etc.) and s/assert can be disabled. The first reason is why I'm using it as at the interface boundary, but I'm not sure if this is "over using" spec .. as that seems to be a community concern.

seancorfield01:07:33

I would consider that an over-specification, TBH. Spec is great at the boundaries but I think Polylith components are fairly too granular for that. Using s/fdef and calling s/instrument in your :test :setup-fn might perhaps be OK (but, again, might also cause your tests to be really slow).

Chris Lester04:07:25

I don't have generative tests yet but those I've used extensively before where it made sense. I'll consider moving off of spec for this, although I feel like I'd have to replace spec with similar logic for argument validation (replacing spec with fns). I'm not sure I want to use :pre/:post for that since it throws assertions.

2023-07-07

Channels