Fork me on GitHub

clj -M:poly create component name:blob-store
  Can't create bricks or projects in old workspaces. Execute the 'migrate' command to migrate the workspace. Execute the 'help migrate' command for instructions.


I didn't know I had an old workspace. AFAIK I do have a workspace, that wanting to create a new component in.


help migrate doesn't give an example and clj -M:poly migrate returns Unknown command 'migrate'. Type 'poly help' for help.`


@cjmurphy What is your :poly alias?


Are you using the issue-66 branch or master right now?


Yes, your branch (kind of).


The alias is :poly .


Maybe best I just go back to 'LATEST'...


Sounds like you have a master-based project and you tried to use the issue-66-based poly tool?


I'm sure that's right.


That error seems to be new in which is the latest issue-66 branch (well, aside from two new commits from @furkan3ayraktar).


I believe the only change I made to the source files was The rest are in the test files trying to make CI green 🙂.


I think in this case, the error is actually correct since the tool is supposed to not allow changing an older version of the workspace without migrating.


Yup, I just happened to notice that I was no longer on the latest SHA and the new commit & merge were from you.


My dot-clojure aliases have been tracking the issue-66 branch for quite some time. You should use whatever poly tool your initial workspace create laid down.


I believe there will be a migration from master-style projects to issue-66-style projects once issue-66 is "fully baked" and ready to be integrated to master.


Yes was using the issue-66 branch. But I'll use the latest SHA now... Yes all that makes sense.


"latest SHA" -- you mean go back to master (and the Clojars release of poly)?


Yes bb594393e03bd97a03109775cb16815594a13748. The create component command works with that one (LATEST was not accepted).


Migration from master to issue-66 isn't hard but it also isn't trivial.


Is there a way forward when you start to have lots (like 100s) of components? Are they all just under the components package, or can that package be further divided? For example domain, utility, stateful etc.?


@cjmurphy I view that as a "feature" because your repo is flatter and you have to think more about the names of your components -- which all makes it easier to find code.


How many bricks do you have today? Before we migrated to Polylith, our 113K line code base had ~42 "subprojects" and now we have 23 components and 16 projects and still have an additional 40 or so "subprojects" that are yet to be migrated.


I'm thinking of a component as a ns that has functions. That's why I'm thinking I'll end up with too many to manage. The legacy code I'm translating from has small (as in LOC) namespaces. But even many domains can easily have a 100 or so entities, each of which will become a component surely.


I'm thinking I'd better have one big component (interface-wise) called utils that subsumes many namespaces, examples: time-utils, dbg, resolver-queries, generic-queries, datomic-utils etc.


We actually started by breaking up our utility namespaces into multiple components.


This is the size of our codebase:

Clojure build/config 22 files 398 total loc,
    76 deps.edn files, 1251 loc.
Clojure source 385 files 90471 total loc,
    3638 fns, 1030 of which are private,
    571 vars, 33 macros, 90 atoms,
    85 agents, 23 protocols, 66 records,
    788 specs, 31 function specs.
Clojure tests 409 files 24079 total loc,
    4 specs, 1 function specs.


how do you get such metrics?


@U0DB715GU It's just a shell script that does a few find and fgrep commands and runs the results through wc.


Clojure build/config 21 files 369 total loc,
    94 deps.edn files, 1513 loc.
Clojure source 414 files 97212 total loc,
    3926 fns, 1058 of which are private,
    614 vars, 34 macros, 93 atoms,
    85 agents, 23 protocols, 66 records,
    810 specs, 31 function specs.
Clojure tests 441 files 25847 total loc,
    4 specs, 1 function specs.


You can see the increase in deps.edn files as we've been refactoring to Polylith.


And this is where we are on our Polylith migration

projects: 16   interfaces: 23
  bases:    3    components: 23


Thinking in terms of metrics something useful for starting out would be the ns-s that a ns uses and those that it is used by. Those kinds of metrics could help with determining which ns-s to combine together to get components. A DAG diagram might help. The goal I guess is to end up with utils style components that are used by a lot of other components and domain style components that use a lot of other components.


@cjmurphy I have recommended people to work in the master branch instead of the issue-66 branch for reasons explained at the top of the Sean’s team is the only team I know of, outside the team I work in, that has used the issue-66 branch in production (which has been great, because he has reported problems that I have fixed). Right now I put a lot of effort trying to get the issue-66 branch into a state where it can be merged into master which I hope will happen in a near future. If you use the poly tool from the issue-66 branch, you will have a workspace.edn file at the root + a deps.edn file per brick. If that is the case, continue using the issue-66 branch, otherwise, continue using the poly tool from the master branch until the migration tool is ready to be used.

👍 4

@cjmurphy I would recommend having small components even though you end up with many of them, it’s a good thing. When you have smaller components with good names, it becomes very easy to compose them in different project when the need arises. We have 80 components and 7 projects (including development) at the moment with ~25K LOC in the workspace.

👍 10