Clojurians Log v2

A question about the cardinality of bases: is the expectation that a project has exactly one base (and multiple components) or are there common situations where a project might have multiple bases? (asking in the context of naming and whether cardinality can play into it)

We have only used one base per project so far (none for libraries). I guess it could be relevant if you have huge APIs (e.g. REST) where different teams are responsible for different parts of that API, but that’s not something we in the Polylith team have any experience of.

I'd stick with base, it doesn't take long to learn what is meant by the name base. It makes sense to me in the context of the lego analogy. Personally I never had any issues understanding what a base is.

As someone who has been putting a lot of time in to moving a project in to a Polylith structure, I'd rather things stay as they are unless there are large and obvious reasons as to why they need to change.

I guess it depends, maybe they could be two separate components?

Nice feedback @allandaviesza, sounds reasonable.

I’m just curious about a thing. Do users of the poly tool use the latest version of tools.deps and live with the warnings you get, or do you use an older version? ( @allandaviesza and others)

I'm currently living with the warnings

We'll modify our project once the version of the poly tool that is kinder to tools.deps is released

Yes, I’m currently working on it @allandaviesza in the issue-66 branch. The tool will be backward compatible with the current tools.deps format, so that you can go back in time with git checkout and still view older versions of the project and use commands like info ,`libs`and deps. I will modify the current poly-migrator tool so that it can migrate from :toolsdeps1 (which is what I call the current version in the code) to :toolsdeps2(next version) which will support the new format that uses :local/root when specifying the bricks in a project. I also realised that it would simplify the migration from the old Leiningen version if the tool could read that format too, which is almost fully implemented in the issue-66 branch. A result of this is that people who still use the old Leiningen based version can use all commands in the poly tool except the create command, and when migrating to the new version, the old code can still be visualized by the poly tool, which I think is kind of cool.

sounds great!

It would also be interesting to hear more about your experience with Polylith so far.

You are mixing languages within the same component here + that it contains two separate interfaces also. My gut feeling says that the two “components” should be separated and live in two separate src directories . The UI code could either live in its own src directory, or together with other ui code, optionally in a separate base which another team here did (we haven’t). But with that said, feel free to experiment @jean.boudet11!

hey folks! I came across polylith and decided to give it a try by migrating one of our microservices to use it (hopefully the others will follow 🙂 ). I was able to setup a workspace and put everything under a base from our project and tried to run the tests with clojure -M:poly test :all :dev but I got the following error Unknown library type: git which is coming from https://github.com/polyfy/polylith/blob/issue-66/components/test-runner/src/polylith/clj/core/test_runner/core.clj#L15 (I’m using Sean’s project as a base) and caused by the fact that one of the project’s deps is defined using git/url in deps.edn. My the question would be that it is possible to use git deps with polylith or it is against the principles and these should be migrated to be a component?

Hi, I spotted great piece of work here and I just created https://aur.archlinux.org/packages/polylith-bin/ for ease installation for those using ARCH Linux distro.

Nice that you like Polylith, and thanks for contributing to it!

Hi @meszaros.jns and thanks for reporting this problem. This is something that I expected to work! We will have a look :-)

Great, thanks 😊 I was able to work around it for now using local deps

If the “normal” cardinality is one base in each project, then I would say stick with bases at this point as it makes sense with the LEGO analogy: each project is built from one base and a bunch of components. In general. Even if a base is reused across multiple projects. And even if occasionally a project somehow combines multiple bases.

Okay, great! And as a side note. The issu-66is not 100% production ready, and I will make some breaking changes in the inner format (what you get when executing e.g. poly ws out:ws.edn ) so if you start using it from that branch, then the output of this file will change a bit over time + small refactorings of the workspace.edn config file will also happen. But for people who only work from the master branch, a migration tool will take care of all this the day the branch is merged/released to master.

Thanks for the heads-up, I'll use master then 😊

@dharrigan Helped me a bit with polishing it. Thanks!