by "like git" I take it you mean a collection of many separate binaries, rather than a single binary? from first principles, each such command would be implemented by a base paired with a project. using git as an example, all the logic for actually working with repositories, commits, refs and the rest would live in a bunch of components. the base for each command would simply convert between the CLI interface and calls to those components.

So a project would then package together the collection of bases? 1 project, many bases? Sorry--missed the first part about the paring one base to one project. Is it still possible to replicate the git command/subcommand structure within Polylith? Or would that be done outside the workspace?

no, a project is generally a single base and several components. a project packages up a base (and its dependencies) for deployment.

certainly it's possible. why can't you have a dozen base+project pairs?

Each project produces its own uberjar, correct? So, for example, three subcommands would generate three uberjars. How are these three uberjars combined to replicate the command/subcommand structure?

the central command (`git`) calls each of them, through the shell.

Got it! Thank you for the clarification!

if you want them "combined" into a single jar, then we're not really talking about git's style. rather we're talking about a single binary with lots of different subcommands. that would be one project, one base, that's pretty thin and just calls through to a bunch of components that do the real work.

(the power of polylith comes from being able to have both of those approaches coexist, and share 98% of their code in the form of the components.)

While it might not make a practical difference, the idea is that base does not depend on components; it depends on interfaces. It is the project that then decides that which components are included to implement those interfaces

So you can start from a project, where the functionality of a component is implemented by a local function call, but then introduce an alternative deployment (a new project), where the same base is used without modifications, but the component is switched to one that actually does remote calls to an external service. The reasons for doing that can be anything; dev/test vs production, monolith vs microservice or lambda, testing a new version

That’s interesting! I’ve been doing Zettelkasten for almost a year now (I’m up to 2500 notes), and Furkan’s startup is building a https://www.scrintal.com. 🙂

I have joined the waitlist! A flat namespace of atomic {components|notes} with {dependencies|references}. The {app|article|book} emerges as the end result of the flat namespace rather than an initial goal. Both are elegant bottom-up approaches. Another tool that I've incorporated into this workflow (actually asked @U2BDZ9JG3 to enable PDF generation for the Polylith Gitbook so I could import the PDF) is https://www.liquidtext.net/. (No personal affiliation). https://www.youtube.com/watch?v=nTHfjt9rgWQ

I actually never thought about it in that way! Let me know if you are willing to try Scrintal.

@U2BDZ9JG3 I would love to try Scrintal! I signed up for the waiting list using <mailto:[email protected]|[email protected]>

Awesome! I’ll DM you further information!