polylith 2022-01-27 | Slack Archive

maxt14:01:54

I’m starting with polylith, and I find that copying the function signatures from the implementation to the interface is annoying. I still like the idea of the separation though. I’m thinking about, as a starting point, generating these signatures. Have others have the same thought?

tengstrand15:01:19

Are you migrating an existing codebase or writing code from scratch?

maxt16:01:01

I’m rewriting an older project

maxt16:01:26

But I started from scratch

tengstrand16:01:56

There are no tools that I know about that could generate a first guess of an interface.

maxt16:01:51

Ok, thank you. Then I might play with the idea, I’ll let you know if I do.

👍 1

seancorfield19:01:10

I think everyone finds it a bit annoying at first, but I've found that it's a good time to think about docstrings and function ordering. I tend to keep my interface files in strictly alphabetical order and have the docstrings focused on users/client code calls, but my impl files in grouped functionality order and docstrings focused on future maintainers.

🧠 1

👍 2

maxt19:01:04

I was just about to ask about docstrings. That was helpful, thank you!

timo16:01:33

Given a polylith project with global extra-deps, when I update a global dependency, then how do I get the dependent projects and trigger a CI?

timo16:01:40

Or is it not possible to define dependencies globally for all the bases/components?

tengstrand17:01:56

You can only add library dependencies to the component, base and project level, not to the workspace top level. The way to go is to add the “global” dependency to all your projects.

timo08:01:45

The https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app has this deps.edn-file in the root-level...what about these deps defined there? Why are they defined there?

timo08:01:17

I've read the whole docs, but probably didn't save that.

tengstrand08:01:04

The :dev and :test aliases in the root deps.edn file configures the development project. All other aliases in that file configures things you want to do with the Clojure CLI, for example specifying the alias`:outdated` to use https://github.com/liquidz/antq.

🙏 1

seancorfield19:01:23

Q about public dynamic vars and Polylith: I have some (currently legacy) code that has a public dynamic var that callers need to set via binding when calling into the module. The dynamic var is part of the public interface but it's also something that the implementation has to rely on. Given that, in Polylith, the interface requires the impl, I can't put it directly in the interface because the impl could not require the interface. Is this one of those cases where something like top.brick.interface.dynamic would be a good location, so that both client code and the brick implementation can require it, much as is recommended with protocols? (i.e., top.brick.interface.protocols)

tengstrand07:01:15

I think this is the right way to go. Putting the shared code in the sub-interface looks clean to me.

emccue06:01:27

If the only operations you are doing on the dynamic var are reading and binding, you can just expose some functions in the interface that do the same job

emccue06:01:54

I.E.

;; impl
(def ^{:dynamic true} *some-var*)

(defn some-var []
  *some-var*)

(defmacro with-some-var [new-val body]
  (binding [*some-var* new-val]
    `~body)))

;; interface
(def some-var impl/some-var)

(defmacro with-some-var [new-val body]
  `(impl/with-some-var new-val body))

emccue06:01:17

then just find+replace your binding usages + usage of the var

2022-01-27

Channels