Hi @U11EL3P9U! I haven’t heard Clip before so I can’t comment on that. I know some people uses Stuart Sierra’s Component with Polylith. We use mount in our project at work. We have states in several components that fetch configuration from AWS Systems manager when they get initialised, so we do not have config files around. Mount states depend on each other by just requiring a state from another namespace, which goes well with Polylith’s idea in my opinion. However, I haven’t actually used other options like Integrant or Component in a real project to say mount is better or worse. You can have a look at https://app.slack.com/client/T03RZGPFR/C013B7MQHJQ/thread/C013B7MQHJQ-1636972221.236800 and also check out @U04V70XH6’s https://github.com/seancorfield/usermanager-example/tree/polylith to see how you could use Component in a project.

Thank you. I'm currently experimenting with integrating Juxt Clip in a fresh example project to see how it might work. Let's see what happens!

I suppose (not related to clip per se), but a -main being a public API should go into base?

Exactly, external/public API’s should go into bases

ta

I think I have the info I need 🙂

😄

I think Component users initialise their state in the bases as well.

:thumbsup:

Well, got it to work with Juxt Clip

pretty straight-forward

If you have a public repo, it would be nice to share with the rest of the world! 💪

I could do 🙂 I want to redo it, and tidy things up.

Going to ask a question in the main channel...

Duplication of dependencies only necessary in case you are using Cursive IDE (https://github.com/cursive-ide/cursive/issues/2554). It’s also mentioned https://polylith.gitbook.io/poly/workflow/testing#how-tests-are-executed in the documentation.

Interesting. I don't use that (I use vim + conjure). Will read and digest.

Ah right, so in my workspace deps.edn, I can reference, for example, {:extra-deps {bases/rest-api {local/root "bases/rest-api"}}}}

and it will pull in those deps

:thumbsup:

Hi! There is no command for that in the poly CLI at the moment. What is your use case for this? If we can justify it, we can add a new command for this. It wouldn’t be too hard to include it in the CLI tool since we have the code for calculating the classpath for the tests already in the workspace.

NVD checking, using a tool like https://github.com/rm-hull/nvd-clojure

the main input to that is a classpath

I figured it wouldn't be too far from what's already available

Should I open a github issue?

Also, while I'm here asking questions, how difficult you think it would be to add a command to poly CLI that returns the commits that affect a project? We're trying to figure out how we could keep https://clojurians.slack.com/archives/C013B7MQHJQ/p1645449050736409 for our projects once they are migrated

Yeah, you can open a Github issue.

For the latter, I’m not sure but @U1G0HH87L could answer that better. If we have it somewhere in the code, maybe we can include it in the workspace map, so that you can extract from there. I think, a separate command for this could be to much for poly tool, however, that’s just my opinion. Also, @U1G0HH87L is playing with letting users of poly CLI to add their own commands to the tool. Once that happens, this could be something you can add easily, as long as it’s in the workspace map.

While waiting for custom commands to be implemented, you can create an alias in your workspace and include the the polylith repo, see how :extra-deps is included https://github.com/polyfy/polylith/blob/4189a30782f1ed21aa1fb55e50355bd862e4b339/examples/doc-example/deps.edn#L27 + your own code that uses the poly code to read the workspace. The workspace contains which bricks a project contains, e.g. projects:poly:component-names:src. Based on that information and the bricks, you should be able to implement this yourself (with support from me, if needed) @U08BJGV6E.

Thank you both!