Clojurians Log v2

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 t:

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 info command.

Well, that’s what I wondered about since here’s what poly info shows and poly diff:

(! 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
...

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. clojure, clojurescript , kotlin , 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 git-root-dir in 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.

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 backend and worker. Basically, with one extra project, I was able to achieve a single server for staging! 😎.

(! 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”…