Clojurians Log v2
polylith
The whole Polylith team, me, @furkan3ayraktar and @james are going to the https://2024.heartofclojure.eu and we are really looking forward to it! See you there!
Awesome, see you there!
Cool! See you there 🙂
Will any of you be at Conj next month?
No, unfortunately. I wish I could come! It’s on my wish list, one day…
The same answer for me, unfortunately. Couldn’t make it this time.
Hey, it was really nice meeting you at heart of clojure! Greetings from Otto
It was great fun meeting all the users of Polylith!
Hi
What is the recommended way to reuse components in a different workspace? Let’s say I have a strings component with useful string related functions, and now I just keep copying it from project to project.
I can’t have all projects in a single repo because I’m consulting different clients, and each client gets a separate repo for obvious reasons.
Decided to ask first, before figuring out how to do it with git subtree or something. Thanks!
I think that's just called a "library"
Great, so you suggest doing exactly what polylith helps me not to have to do — manage each component as a separate library, update versions etc.
it is the form that exactly captures the relationship between the code bases you are describing
Then I want a different form 🙂 Also, the point would be to be able to interact with this “library” code the polylith way, editing it in one place interactively, without having to commit a new version to use it in dev. I mean, of course you can call it a library, but I want a seamless way to extract it into a private library out of the monorepo.
the reason code works in a mono repo as versionless dependencies is that it is being developed together in lockstep
introducing an unversioned out of tree dependency sounds like a nightmare
Yes. So I’m looking for a better way
That’s why I mentioned git subtree. Maybe just put all of these components into one separate repo, and subtree into each workspace that uses them.
I am open to hearing what could be a different solution to this problem. We have brainstormed a lot about this in the past (and now, on the plane with Joakim while travelling to the Heart of Clojure), and we could not find a solution that satisfied us and was better than a library. There may be a solution somewhere that we haven’t discovered. A good solution to this problem would be a great addition to Polylith’s offering.
Well, now you really got me thinking too 🙂
I’ve had good results treating “components” as its own git repository of “LEGO pieces”. Depending on the circumstance, I’ll symlink, submodule, or subtree into a workspace. It’s become the “chest of LEGO pieces” that are used in different workspaces.
never used subtree before, does that merge the foreign "components" folder into your repo's components folder?
I use components as a single repo. All my components live there so no components merging is necessary. Each workspace may work on a separate branch of components and merge/rebase as needed using standard git workflows. It’s one communal LEGO bin shared among workspaces.
Depending on your needs, you may be able to symlink a components repo as a start.
@nkabir Symlink is something I definitely don’t want to do, since I want it to be accessible from the repo.
But a subtree of one repo with common components should be workable
Certainly--a symlink is the simplest yet least versatile option.
Symlinks don’t play well with Clojure CLI/Deps projects.