This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (26)
- # beginners (42)
- # calva (3)
- # cider (5)
- # cljs-dev (7)
- # cljsjs (1)
- # cljsrn (13)
- # clojure (95)
- # clojure-europe (12)
- # clojure-germany (3)
- # clojure-italy (12)
- # clojure-nl (1)
- # clojure-spec (16)
- # clojure-uk (25)
- # clojurescript (13)
- # clojureverse-ops (5)
- # community-development (1)
- # conjure (8)
- # cryogen (3)
- # datomic (5)
- # deps-new (7)
- # exercism (1)
- # fulcro (34)
- # honeysql (9)
- # hyperfiddle (3)
- # instaparse (2)
- # introduce-yourself (2)
- # jobs (6)
- # kaocha (1)
- # lambdaisland (1)
- # lsp (47)
- # malli (3)
- # membrane (38)
- # off-topic (9)
- # polylith (36)
- # reitit (7)
- # releases (1)
- # remote-jobs (2)
- # shadow-cljs (11)
- # spacemacs (7)
- # sql (7)
- # tools-deps (19)
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.`
Sounds like you have a master-based project and you tried to use the issue-66-based
That error seems to be new in https://github.com/polyfy/polylith/commit/99a044b02f2bcc0b6525dbee3dca3fa5f2966cea 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 https://github.com/polyfy/polylith/commit/2927d7714ebde86d1a00346774a13a1edf28a185. 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.
Yes bb594393e03bd97a03109775cb16815594a13748. The create component command works with that one (LATEST was not accepted).
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.
@U0DB715GU It's just a shell script that does a few
fgrep commands and runs the results through
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 https://github.com/polyfy/polylith/tree/issue-66. 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.
@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.