Another subproject refactored into a component. Tomorrow will be some of another subproject. The downsides of having subprojects that become “grab bags” of random functionality! 😞
I have an issue where if i run poly create component name:be.router.reitit interface:be.router
i get the following after running poly info
I can go around it by using dashes instead of dots but it doesn't quite look idiomatic.
I was a bit surprised you can create an interface with a dotted name at all, but I see it creates the appropriate nested file structure (`components/be.router.reitit/<prefix>/be/router/interface.clj`). I just expected everything to be at the same depth and for a dotted name to be disallowed. Will be interesting to hear what @tengstrand says about that.
I mean it works mostly fine, the namespaces correspond correctly to their path, and it feels like a nice way to group up components
Although if you create 2 components with the same dotted prefix they won't be grouped together under the same dir as java packages-style
Which is not necessarily bad
After introducing a :git/url dep, I am now getting the following error message when doin poly test
Unknown library type: git
Does anyone know how I can get more info than this? Does polylith have any additional log files when it runs tests or something?
@austin021 Which version of poly
are you using? That works with the latest git version from the issue-66 branch. Maybe it just isn’t supported in the version you’re using?
I wouldn’t expect them to — the component names would be unique and everything is grouped “by component”.
No, this should not work, and I’m really surprised that it does! 🙂
0.1.0-alpha9
{polyfy/polylith
{:git/url "<https://github.com/polyfy/polylith>"
:sha "76936c752fb5b729c216b23d92c8a8d71cfdc92f"
:deps/root "projects/poly"}}
Maybe :git/url
just isn’t supported on the master version? I’m on 2de60069edbba960b8ab9e71dc6c2341615a52ec
which is the latest issue-66
branch (which has a lot of changes from master — including quite a few breaking changes I believe).
Yeah, switching to that branch fixes it. Thanks!
Hmm, I didn’t think issue-66
was compatible with master. I’ll be curious to hear of any problems you run into after making that switch… (I figured I’d start with issue-66
’s branch since I’m just getting started with Polylith and I need some of the changes that branch supports)
Huh. Actually, it only fixed things for my local machine. It just slightly changed the error message for CircleCi java.lang.Exception: Unknown library type: git
Is CI running poly
or clojure -M:poly
?
clojure -M:poly test
, which is the same as what I tested with on my local machine.
Well nevermind. I am reading through my local logs and it is the same. I wonder what I read that made me think it worked!
@seancorfield, Since you say it is incompatible, where can I look to change to the new version's config? I am also mostly just starting with polylith as well. What are the things it supports that you need?
Ah. Info is at the top of the Readme of the branch. nevermind.
Yeah, the diff is pretty enormous: https://github.com/polyfy/polylith/compare/issue-66
I won’t attempt to summarize it — @tengstrand could do a better job — but I think it’s mostly that components have their own deps.edn
files now and there’s a workspace.edn
file at the root which contains the poly
-specific information (moved from deps.edn
) and the workspace-level deps.edn
is now about just the :dev
/`:test` alias stuff.
This much more closely matched how we were already using the Clojure CLI — we’ve had a monorepo for years and been using deps.edn
since some time in 2018 and we’ve reorganized it a few times as the CLI has evolved. We had about 40 subprojects and 113K lines of code before we started to migrate to Polylith.
Yes, if I remember right, I only fixed that :git/url
problem in the issue-66
branch.