This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (53)
- # beginners (158)
- # calva (25)
- # cider (21)
- # clara (1)
- # clj-kondo (12)
- # cljsrn (6)
- # clojure (94)
- # clojure-australia (2)
- # clojure-bay-area (6)
- # clojure-europe (40)
- # clojure-nl (10)
- # clojure-spec (16)
- # clojure-uk (18)
- # clojurescript (95)
- # cursive (14)
- # data-science (1)
- # datascript (6)
- # datomic (18)
- # depstar (2)
- # duct (36)
- # emacs (15)
- # events (4)
- # fulcro (16)
- # graalvm (10)
- # helix (25)
- # honeysql (6)
- # jackdaw (4)
- # jobs (2)
- # leiningen (24)
- # lsp (4)
- # malli (10)
- # off-topic (3)
- # pathom (3)
- # polylith (19)
- # practicalli (4)
- # prelude (1)
- # re-frame (6)
- # reagent (13)
- # reitit (3)
- # remote-jobs (10)
- # ring (12)
- # ring-swagger (2)
- # shadow-cljs (54)
- # testing (17)
- # tools-deps (10)
- # xtdb (14)
I’m building out a new, small, command-line app at work and using Polylith for it. I’m not seeing the
* that indicates code updated since a stable tag so I have to debug that tomorrow. The main obstacle I have run into so far is that, because we rely heavily on
:override-deps in our current setup, it’s hard to reuse “legacy” subprojects because I can’t tell the
poly tool to use an alias to pick those up (I could perhaps duplicate the subset I need into the
:dev alias and into the project’s
deps.edn file somewhere. I might try that tomorrow. The other thing I’ve realized is just how “big” and somewhat “generic” some of our existing subprojects are and how interdependent they have become: I wanted to pull out just our “environment” component so that I could reuse the machinery that figures out how to set up our DB connection pool and it just dragged in so much other stuff… ugh! We need to refactor to smaller components! 🙂
I did figure out a way to call into the new Polylith-structured stuff from our existing subprojects and also run tests and make uberjars — so that at least paves the way for us to refactor things out of subprojects and into components!
Okay, cool that you figured out a workaround and it will be interesting to follow your progress! I plan to support
:override-deps in some form, but it’s not at the top of my prio list right now. The
poly tool doesn’t calculate dependencies based on the test context, and I’m implementing support for that right now. One result of this is that the
deps command will be able to show dependencies that are only used from the test context and mark them with a
And one more thing. You can run
poly diff to see what changes the
poly tool base the changes on (marked with
* when running the
Well, that’s what I wondered about since here’s what
poly info shows and
(! 623)-> clojure -M:poly info :all :dev stable since: 1690953 | stable-sean projects: 2 interfaces: 1 bases: 1 components: 1 project alias source -------------------------------- google-search-job gs --- development dev --- interface brick gs dev -------------------------------------------- --- --- google-search-console google-search-console xxx xxx - google-search-cli xxx xxx Tue Apr 13 17:32:58 (sean)-(jobs:0)-(/Developer/workspace/wsmain/clojure) (! 624)-> clojure -M:poly diff ... clojure/bases/google-search-cli/deps.edn clojure/bases/google-search-cli/src/ws/google_search_cli/job.clj clojure/bases/google-search-cli/src/ws/google_search_cli/main.clj clojure/bases/google-search-cli/test/ws/google_search_cli/main_test.clj clojure/components/google-search-console/deps.edn clojure/components/google-search-console/src/ws/google_search_console/impl.clj clojure/components/google-search-console/src/ws/google_search_console/interface.clj clojure/components/google-search-console/test/ws/google_search_console/interface_test.clj clojure/deps.edn ...
diffthinks lots of things have changed but
infoisn’t showing the
I suspect it’s because the git root is above the current directory where the
poly tool is running?
Our monorepo repo is structured as:
build/ -- build scripts and configuration etc clojure/ -- all the Clojure code, including the Polylith stuff documentation/ -- our API docs etc
So it would seem that
info needs to take into account the difference between the git root and the “poly” root?
I think you are right. One solution could be to support several workspace roots within the same monorepo. That would also allow the tool to support more than one language, by having them in separate top directories, e.g.
java and so on, but it would also solve your use case. Then e.g.
clojure/workspace.edn could specify which directory is the git root (or it can walk upwards the directory structure and check for the root by running a git command) whereas the workspace root would be
clojure in this case. I’ve been thinking of a solution similar to this recently, so maybe this is how we should proceed. The good thing with this solution is that it will not break any existing workspaces.
I think maybe adding a
workspace.edn would be the best solution.
In the meantime, you can run the tests with the`:all` argument. I will try to finish what I’m working on in the weekend, and then I can have a look at this.
Cool. Thank you! Yes, either specifying
workspace.edn or walking up the directory tree from the folder containing that file, to find git repo? The latter is pretty common in tooling, I think, and wouldn’t be hard to write.
Even though I’m part of the Polylith team, I learn new ways of utilising it in my day-to-day job. Today, I did a very cool thing and I thought it might be nice to share with you folks.
I have two projects in my Polylith workspace, named
worker and `backend`, which are deployed to two separate servers. They each have a base within them. Since we are a small startup, I didn’t want to deploy two servers for staging environment, to cut some costs. So, instead, I created a third project in the Polylith workspace, named `staging`, which uses the two bases from `worker` and `backend`. Also, I merged the
deps.edn files of both
worker. Basically, with one extra project, I was able to achieve a single server for staging! 😎.
Our first Polylith project at work 🙂
(! 521)-> clojure -M:poly info stable since: 1690953 | stable-sean projects: 2 interfaces: 3 bases: 1 components: 3 project alias source -------------------------------- google-search-job gs --- development dev --- interface brick gs dev -------------------------------------------- --- --- google-search-console google-search-console xx- xx- seo-keyword seo-keyword xx- xx- site site xx- xx- - google-search-cli xx- xx-
Looking forward to see another blog post about it 🙂
Haha… yeah, I need to figure out a story for
:override-deps first. I have a scenario in mind and will be testing it “soon”…
Wow, well done!
I gave up on
:override-deps — with the way the test runner works, I couldn’t figure out how to get it working.
That’s OK for now …