polylith 2022-12-20 | Slack Archive

seancorfield20:12:40

The final part of that migration left me with a question and also a potential bug in Polylith (as far as I'm concerned): • poly check does a great job of making sure the project :deps contain all the necessary bricks but if the :aliases > :test > :extra-deps add more bricks, poly check does not check whether those bricks' transitive dependencies are satisfied -- this can lead to a very painful process of doing poly test, getting a ns not found error, adding that brick, running poly test again and getting a different ns not found error (missing transitive brick), rinse and repeat... I think poly check should also check test dependencies and indicate which of those are missing separately from the main deps (I know it's a harder problem to solve but it would have saved me from quite a bit of pain, several times, during this migration. • we have a couple of bases that are somewhat related -- member-facing billing app and background job for rebilling periodically -- and the tests for the rebilling base use the member-facing base app to set up the complex conditions that are needed for the various rebilling test scenarios; now, clearly, I can (and do) have the rebilling base's tests depend on the member-facing base's main ns to make this possible but I'm wondering what other folks are doing in similar situations, or if anyone even has a similar situation? And that's how I spent quite a while trying to address the first bullet, because of the second bullet. I wondered if I could have the rebilling base's tests depend on the member-facing project but Polylith doesn't seem to figure out the right dependencies that way.

tengstrand07:12:31

Maybe you could create an issue about the problem with the check command @U04V70XH6?

furkan3ayraktar08:12:58

I haven’t thought about the second bullet point extensively, yet I can tell how we handle it currently. We regard the tests using another project’s base as integration tests. We have project-level tests where we define the necessary dependencies in the project’s test alias. The bases have their internal isolated tests under their own test directory, and inter-base tests are under the projects test directory.

seancorfield16:12:33

> Maybe you could create an issue about the problem with the check command Sure. I wanted to check that it was considered something that needed fixing first. https://github.com/polyfy/polylith/issues/272

👍 1

seancorfield16:12:46

@U2BDZ9JG3 Thanks. moving these tests to the project level would make sense (but I've had some weird behavior with tests in projects so I'll report back on whether that works as expected for me -- but it'll be a while before moving those tests becomes a priority, now that we have them working.

👍 1

Travis20:12:38

I am having an issue that I cannot seem to spot what is going on. When I run poly check its telling me that my project is missing a component for interface "x". This project should not have any dependency on that. The only wrinkle here is that I have two components that implement the same interface and one of those components use interface "x" in its impl. The component that I am using in this project uses the other component/implementation. I am not quite sure how to track this down or if I made any sense. A little hard to explain

Travis20:12:05

Do you have to have include components for other interface implementations in the project ?

tengstrand07:12:01

Yes, if let’s say component A depends on interface B. Then if you include A in a project, then you also need to include a component that implements the interface B into that project.

Travis14:12:35

What i am kind of seeing is the following

interface X -> Impl A -> uses Brick B
interface X -> Impl B
Project -> uses Impl B

In my case its forcing a dependency on "Brick B" but the project is not using that Interface X with Impl A

tengstrand15:12:40

Okay, so we have an interface X, and two components X1 and X2 that both implements X, where X1 refers the interface B, but X2 doesn't refer B. Then we have a project P that contains X2. Then the poly tool complains that P doesn't contain an implementation for the interface B? If this is the case, then we have a bug.

X1 -> B
X2 -> 
P -> X2

Travis15:12:14

That is what it seems like is going on to me

tengstrand17:12:55

Can you create an issue?

Travis17:12:26

sure

Travis17:12:21

i just tried setting up an example project and its not exhibiting the issue so maybe its something else going

Travis19:12:46

Still thinking its a bug but i have no idea how to reproduce it, lol

Travis19:12:42

I have been grepping code and running "poly deps" on all the bricks and everything looks good until you get to the project. Also a test i commented out the requires for the downstream brick in the interface and that made the error go away. So per our example commenting out B in X1 made P work with X2

Travis20:12:58

Only workaround i can think of is to swtich to protocols

tengstrand21:12:23

Could you run poly ws out:ws.edn and send me the file + deps.edn at the root and workspace.edn?

Travis21:12:52

unfortunately i don't think I can, i might be able to give certain chunks of it

tengstrand07:12:33

Maybe you could try to copy your codebase and remove one thing at a time, till you realise what the problem is?

Travis14:12:35

Yeah, also I think I have a better idea that would eliminate the need for having multiple components with the same interface in this case

Travis14:12:48

Simplify things a bit

tengstrand14:12:09

Okay, sounds good.

Travis14:12:23

appreciate the help

👍 1

2022-12-20

Channels