polylith 2022-05-11 | Slack Archive

tlonist01:05:10

Perhaps a flashback to @jungin.kwon1’s https://clojurians.slack.com/archives/C013B7MQHJQ/p1650609194542669, are there any ways to manage the top-level deps.edn elegantly, without having to copy&paste all dependencies with :dev alias to support various IDEs(like cursive)?

tlonist01:05:14

Or is anything being done or discussed regarding this issue? What I find cumbersome is that the shape of repository should depend on tools developers use.

seancorfield01:05:21

Petition @U0567Q30W about https://github.com/cursive-ide/cursive/issues/2554 ?

✅ 1

seancorfield01:05:36

At work, since no one uses Cursive, we have :local/root extra deps for all the bases and components in our workspace level :deps alias (and :extra-paths for the tests stuff to support testing via the :dev project). Our 3rd party library deps are only in bricks' deps.edn files, except for ones we need to supply differently between :dev for the REPL and projects for building artifacts.

✅ 1

tlonist02:05:26

Thanks for sharing. So the feature is included in Cursive's 1.12 milestone!

cfleming22:05:52

Yes, fingers crossed on that one, but it’s surprisingly tricky.

🙏 1

Gary Berger14:05:51

Might be off topic, but building an interactive CLI app using polylith architecture, Before I go too far into the rabbit hole, Could I reuse the poly shell component as a base interface or is it too implementation specific to poly .

imre15:05:00

How I understand it so far is that bricks (bases and components) are only for internal use in a workspace.

imre15:05:28

Anything that's for outside consumption either as an app or a lib will be wrapped in a project

imre15:05:10

In a recent PR to the poly tool I was asked to change the name of a component so I wouldn't consider those to be part of the "public api" of a poly workspace

Gary Berger15:05:50

got it, tks

imre15:05:58

mind that I'm not part of the poly team, only a dev in the process of adopting it

2022-05-11

Channels