Question: why the namespace?

[fraser-langton]

I have been playing around with uv as a build tool for cloud artifacts for a while and I love this tool so far!

I was wondering what the motivation for every brick to be in the same namespace? So that every import is from the same namespace - it just feels unecessary and not as pythonic as having the namesapces be the names of the bricks themselves

Also - in the example for python I see the dependecies are declared in the root pyproject. How come uv workspaces aren't encouraged to split up dependencies for builds?

[DavidVujic]

Hi @fraser-langton, I'm happy that you have found Polylith!

Having the same top namespace is a lot about keeping things simple and clear where the code comes from, it's also about sharing code: making things obvious instead of the risk of hiding code in domain-specific namespaces. Is it not Pythonic?

The root pyproject will have all the dependencies, and all the bricks. This is the environment you work in and where the .venv is created. This can also be accomplished by splitting up the third-party dependencies with uv workspaces (you can do that if you like), but Polylith support all Package & Dependency management tools out there with or without workspace support. I also like the explicit way and Polylith allows for development to begin with just writing code - and later on you can worry about how and where to deploy it (i.e. creating a project and add dependencies). Before that, you'll have everything needed to develop features in the root project (aka the Polylith Workspace).

[fraser-langton]

to the first point, so if you were developing in a commercial setting would you personally just have the namespace be company_name then all you imports are from company_name.foo import bar and import company_name.foo?

makes sense given uv workspaces are unique - I only ask as I have had previous experience with lambdas reaching package limits, and thus we look at creating mulitple based on how they need dependecies and being able to build projects with only the dependecies they declare (directly or through workspaces/bricks) would be neat!
I will add that using uv workspaces and tach report you can cheack your workspaces/bricks declare their dependecies correctly - I came here from tach :)

[DavidVujic]

The first point: yes! You have the top namespace (company_name) and then the individual bricks. A brick can have its own structure with folders and modules if needed. The recommendation is to have a flat structure, and moving out any potential (and what makes sense to logically group) into separate bricks. A brick can be something feature-like or tech/util style. You can also compose one brick from other more low-level bricks.

About the dependencies:
each project should only have the dependencies it needs. So if you have a AWS Lambda, you have it defined as a Polylith project with only the needed dependencies. The root pyproject is for your development environment. You don't deploy anything from that configuration, you only deploy the projects.

Great that you found Polylith from Tach! I am currently working on adding new features to the Polylith tool, inspired by the things in Tach. It's not going to be a 1:1 feature mapping, but you'll hopefully find similar things that accomplish something similar to what's in there.

[fraser-langton]

1 - I think I just respecfully disagree, at least in the repos I have worked with that have a lot of internal imports, it would be very repetitive to import everything from the same namespace. That being said I have been playing around with polylith and you can still have more than one namespace, it just isn't what the cli commands create.

2 - could you imagine a uv integration where the workspaces replace the tool.polylith.bricks? Or would it not be so straight forward?

[DavidVujic]

I'm curious about what you mean with repetitive, maybe I misunderstand something? If you view it from a single-repo perspective, you'll have the code in an app folder or a similar name. You access the entire code base by typing from app import something, or using relative imports. That's exactly how the Polylith structure works. This is just plain Python, and Polylith doesn't do anything different there. You can also view the bases and components as equivalents to a src directory.

The bricks aren't the same thing as libraries, in Polylith you are encouraged to organize the code in much smaller units than a library (that's the LEGO brick metaphor). That means (even if you can) it is not recommended to group the Python code into "sub domains" or layers. Ideally, you won't have a deep structure at all.

About the uv workspaces: there's already support for this in Polylith (I think I have that set up in the uv-specific example repo). Here, we treat the projects as workspaces. I find that much more simple and smooth from a developer experience perspective. Using only uv workspaces and treating the bricks as libraries, you could probably accomplish something "Polylith like" but then you also need its own infrastructure (a pyproject.toml with metadata and dependencies, that would indeed be repetitive 😄 ).

The creator of the Polylith Architecture, Joakim Tengstrand (a friend of mine) wrote an article a while ago that I really recommend. It is focusing on the architectural parts (and here comparing it with the ports & adapters/hexagonal architecture):
https://medium.com/@joakimtengstrand/understanding-polylith-through-the-lens-of-hexagonal-architecture-8e7c8757dab1

[fraser-langton]

A single-repo doesn't have to all be in one dir, ie you could just have multiple modules in root (app, database, payment) or pattern I have work with quite a bit is having a /libs or /src dir which are all first class namespace packages, and more recently using uv (workspaces) to manage the 3rd party dependencies of those libs but also in between each other.

What I am trying to figure out is how you manage dependencies, ie if a brick has a dependency of pydantic added for example - you need that dependency propagated to the projects that use that brick, and that has to be done by the developer not the package manager (ie uv)? Just trying to imagine how this would works with 100s of bricks building 10s of deployable artifacts

Thanks for the article, I think it illuminates how the polylith pattern is conceived to be used

[DavidVujic]

Thanks for clarifying! I think I understand what you mean. You are encouraged to have a more flat structure in Polylith, to avoid "hiding" code in domains. That's the architecture part of Polylith. As an example, the things you would have in the payment root - such as sub-packages and modules - would probably fit well at the brick/component level in Polylith.

About the dependencies: in both scenarios (having dependencies specified in the bricks, or in the projects) a developer need to add them. Once added, both will be managed by uv and with workspaces enabled you'll have a single lock file for both. With pydantic as an example, you could have that dependency in more than one brick and then both bricks would need their own pyproject.toml with all requred metadata + the dependency. I find it more clear with having the dependency specified in the project. But Polylith for Clojure actually has the option to define third-party dependencies in the bricks and I'm not against supporting that here too. The thing that I don't like in Python, is the amount of boilerplate needed in each pyproject file.

I would encourage you to try this thing out and get a feel for the workflow! You'll have the tooling that will notify about any missing dependencies, and also auto-synchronizing the bricks.

[fraser-langton]

I have been playing around a bit in mock projects and will give it a go on a production project, thanks for taking the time to answer my questions!