Improve functionality of "components" (specification of external dependencies & wheel builds)

[jonded94]

Thank you @DavidVujic for your very interesting talk at PyCon, was a joy to attend!

This project could be nice to organize code in a monorepo while also having a drastically lower onboarding cost compared to tools such as Bazel or Pants (although they try to solve slightly different things). Currently, using this tool is a bit blocked or would be cumbersome because of some design decisions about the "components" of a polylith repository:

Specification of external dependencies:

Say you'd have a bunch (aka dozens - hundreds) of components which all individually could have a bunch of external dependencies. These components now are consumed by a bunch of different projects. As far as I understand it, the projects would now to be responsible to specify the external dependencies of the components in their corresponding pyproject.toml's. This leads to a lot of repitition and also potential sources of errors.

Could there be a mechanism of the components to specify their external dependencies? This would move this responsibility away from the projects and also would have the great benefit that running poetry lock on a project which depends on components with conflicting external depencies would fail.

Wheel builds of dependencies:

Sometimes, even when there is already a nicely maintained monorepo, it can be very helpful to have the code of a component available as a wheel in an internal registry. As far as I know, there is no mechanism to build a wheel from a component, correct? This obviously would also need the capability of the component to be able to specify its external dependencies, otherwise one would have a wheel in the package registry for which it's unclear that it depends on.

Thank you very much again for this package! Please understand this purely as a question whether this could in principle be possible or would even be an intended use case for this project.

[DavidVujic]

Hi @jonded94! I'm happy to hear that you liked my talk at PyCon, and thank you for sharing your ideas, much appreciated! ⭐ 🤩

Currently on my way back by night train to Stockholm again.

About components and having them define their own dependencies: I have thought about this and want to to solve this in a simple way. I want to avoid making every component into a "library", with a .venv and lock files and the need to keep track of the versions of depdencies used across the components. I think that could create more complexity.

In a way, I think there is already support for this in the package management tools, by using editable dependencies? It wouldn't be a Polylith brick, though. The Clojure version of the Polylith tool has this thing already (probably by using some native features that we don't have in Python), and I will do some resesarch and hopefully get ideas!

Meanwhile (and a behaviour that I still would consider to be the default), I would suggest to think about the components as very small parts (lego bricks). A component doesn't have to be an entire feature, it could be a smaller part of a feature. It can also be a "tech component", such as the things we normally would put in a utils or helpers folder.

By doing this, I think it is less needed to have the components define the dependencies. There's also the poly check command, that will notify any missing dependencies (both bricks and libraries). Also, the poly libs command will highlight these things (both will return an exit code 1).

An example: