polylith

https://polylith.gitbook.io/ and https://github.com/polyfy/polylith
seancorfield 2021-07-03T00:24:24.161600Z

Q for @tengstrand I think: as we're migrating code around into the Polylith structure, we have new (Polylith) namespaces like ws.<brick>.whatever and we also have some legacy ws.<subproject>.whatever namespaces -- and today I moved some code into Polylith structure that requires some of those legacy nses... and got

Error 107: Missing components in the development project for these interfaces: billing, google-search-cli, messaging
  Error 107: Missing components in the worldsingles project for these interfaces: billing, google-search-cli, messaging
Am I right in surmising that Polylith is going to consider ws.<subproject>.whatever as being something that should be a brick in Polylith even tho' it exists outside in a legacy library?

seancorfield 2021-07-03T17:05:24.162500Z

(on the assumption that I'm correct, I'm just going to migrate more of those legacy nses into components but it just means this current piece of refactoring got substantially bigger!)

tengstrand 2021-07-04T15:42:34.165900Z

@seancorfield I couldn’t reproduced all your problems, but I have tried to fix them anyway. The changes are pushed to the issue-66branch together with other fixes that I was working on. It should fix your 107 error . Try it out to see if you have any remaining problems.

seancorfield 2021-07-04T15:44:31.166300Z

Thanks, I'll update the poly tool to that latest SHA and I'll let you know if I run into any issues on Monday when I'm back at work!

seancorfield 2021-07-04T15:52:56.166500Z

Confirmed that I don't get the 107 error now on code that refers to brick-like nses that aren't Polylith interfaces.

seancorfield 2021-07-04T15:53:26.166700Z

info and test :dev :all both seem to work correctly too.

tengstrand 2021-07-04T18:17:37.166900Z

Sounds great.

tengstrand 2021-07-03T17:55:17.162600Z

Yes, it looks like you are right. The right behaviour should be that it only considers namespaces inside the components directory as interfaces. I can have a look at this tomorrow and try fix it.

seancorfield 2021-07-03T20:20:25.162900Z

Thanks!

seancorfield 2021-07-03T20:22:56.163100Z

One other thing I tripped over during my refactoring marathon was this NPE:

#error {
 :cause Cannot invoke "Object.toString()" because "s" is null
 :via
 [{:type java.lang.NullPointerException
   :message Cannot invoke "Object.toString()" because "s" is null
   :at [clojure.string$ends_with_QMARK_ invokeStatic string.clj 370]}]
 :trace
 [[clojure.string$ends_with_QMARK_ invokeStatic string.clj 370]
  [clojure.string$ends_with_QMARK_ invoke string.clj 366]
  [polylith.clj.core.deps.project_brick_deps$test_QMARK_ invokeStatic project_brick_deps.clj 80]
  [polylith.clj.core.deps.project_brick_deps$test_QMARK_ invoke project_brick_deps.clj 79]
  [clojure.core$complement$fn__5687 invoke core.clj 1443]
  [clojure.core$filter$fn__5912 invoke core.clj 2821]
  [clojure.lang.LazySeq sval LazySeq.java 42]
  [clojure.lang.LazySeq seq LazySeq.java 51]
  [clojure.lang.RT seq RT.java 535]
  [clojure.core$seq__5420 invokeStatic core.clj 139]
  [clojure.core$filter$fn__5912 invoke core.clj 2813]
  [clojure.lang.LazySeq sval LazySeq.java 42]
  [clojure.lang.LazySeq seq LazySeq.java 51]
  [clojure.lang.RT seq RT.java 535]
  [clojure.core$seq__5420 invokeStatic core.clj 139]
  [clojure.core$sort invokeStatic core.clj 3101]
  [clojure.core$sort_by invokeStatic core.clj 3107]
  [clojure.core$sort_by invokeStatic core.clj 3107]
  [clojure.core$sort_by invoke core.clj 3107]
  [polylith.clj.core.deps.project_brick_deps$source_deps invokeStatic project_brick_deps.clj 127]
This can happen if a component's namespace doesn't match its filepath -- it would be nice if the code could be a bit more robust about that and perhaps at least give a better exception, indicating what file or brick it was trying to analyze?

seancorfield 2021-07-03T23:10:00.164800Z

Update on our migration:

projects: 16   interfaces: 23
  bases:    3    components: 23
Three of those "interfaces" are just migrated legacy namespaces, that haven't yet been refactored into implementations (and interfaces). That's Monday's work, while my teammate is taking Independence Day off 🙂

tengstrand 2021-07-04T07:02:14.165600Z

The tool reads components from disk https://github.com/polyfy/polylith/blob/90ca45583036425ccabe932c9517cec34475ba93/components/workspace-clj/src/polylith/clj/core/workspace_clj/components_from_disk.clj#L31 so I guess you now have 23 directories under the components directory?

seancorfield 2021-07-04T15:43:42.166100Z

Right, we have 23 components now, but the ws.messaging.sdk namespace that was referenced in one of those components (actually in a bases entry I think it was) lived under a wsmessaging-sdk legacy subproject: wsmessaging-sdk/src/ws/messaging/sdk.clj which, of course, Polylith doesn't see -- so as far as its concerned, some Polylith code in bases/batch-jobs/src/ws/batch_jobs/messages.clj is trying to reference a brick that doesn't exist (because it's in one of the 40 legacy subprojects). That legacy code has namespaces that start with worldsingles (old code) and ws (newer code) and then I picked ws as the top ns for the Polylith code, not realizing it might "conflict".