Structures for larger repos #189
-
|
I saw a discussion around tooling for larger repos #89, but I was interested in your thoughts on using more subfolders at the bases/components levels. Say I wanted to namespace a heap of components like this in a workspace with the default namespace as
If that were all one big flat list, which I think is the preference, I don't think it would work that well. The repo we will create will get quite large, 100s of projects, and I want it to be easy for developers to navigate to sensibly namespaces areas to find the code they want to work on. Perhaps this is a more pertinent question at the bases level as really, if we just view the top level components as a python package, you just get everything under that directory anyway, the only thing we lose is the granularity/composability of components at the project level. I dont think you're existing toolset is really setup for this, but I think it would fine from a polylith theoretical view? Would love to hear your thoughts on the topic, and how you anticipate large projects should scale to the existing flat structure? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hi @shaneseaton, your setup looks fine to me 😄 In your example, What I usually mean with a flat structure, is to avoid code duplications. Also, to avoid other components importing a large component when it only needs a subset of it, such as the "reporting" feature or even further down such as "datapipeline". It is a general guideline to keep things in a flat structure and to keep the components small. You can think of the components as a lot smaller than an installable library from PyPI. A library is usually an entire feature, but a component is a smaller part of a feature. I think especially in large monorepos that it would be very useful and practical to keep the component small. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that helps clear things up a bit on that front. |
Beta Was this translation helpful? Give feedback.
Hi @shaneseaton, your setup looks fine to me 😄
In your example,
aws,gcpandazurewould be the components from a Polylith perspective. You can have the code in a component structured in several subfolders as in your example.What I usually mean with a flat structure, is to avoid code duplications. Also, to avoid other components importing a large component when it only needs a subset of it, such as the "reporting" feature or even further down such as "datapipeline". It is a general guideline to keep things in a flat structure and to keep the components small. You can think of the components as a lot smaller than an installable library from PyPI. A library is usually an entire feature, but …