In-brick pyproject.toml support

[licht1stein]

In Clojure polylith we have a separate deps.edn for each brick, which allows us to not repeat dependencies in dev deps.edn and project deps.edn — they are merged from all bricks' deps.edn file. Is it possible to have this in python polylith and multiproject?

For example I want to have a component log which depends on a logging library loguru, and this is specified in the in-component pyproject.toml. When I include this in a project, loguru will be automatically installed, like normal library dependency.

[DavidVujic]

Hi @licht1stein,
for the current version of the Polylith for Python I chose to keep it as simple as possible by using Python namespace packages. Earlier versions of the Clojure tool had that setup too!

I have thought about this, and will look into how to make it as simple as possible in Python - without introducing too much third-party dependency hassle in each brick. Today, a brick (component or base) is not a self-contained library, but a namespace package just as if you would have a single-project repo. I think that is easier for bricks that are very small, or maybe using the same third-party dependency (then each one could/would specify it).

But I have this on my radar 😄

[jacksonwb]

I had the same question. It seems like there needs to be a way to describe dependencies that components or subprojects have.

In the above example where would the loguru dependency be documented? In the top level pyproject.toml of any project that used the log component, along side all the dependencies of all other components that that project used?

[DavidVujic]

Hi @jacksonwb, I have added a new section in the docs about dependencies in Polylith:

https://davidvujic.github.io/python-polylith-docs/dependencies/

[zifeo]

@DavidVujic Great work! We are considering to use python-polylith, however we have a setup where components may have incompatible dependencies between them (think of libs with different major version which will never be combined together in final project - yet we wish to keep them in the same repo if possible and take advantage of devcontainers depending on the current need). Having a pyproject per components may help. How would you approach that?

[DavidVujic]

Hi @zifeo,

Sorry for replying so late, I must have missed out on the notification.

I think that would work, since the different projects choose what components, bases and third-party libraries to use.

The thing that won't work is having it all in the Development environment, that is usually recommended to have. The top pyproject.toml is used during development only and in general includes all components, bases and third-party libraries. This is for having all code available during development in the same virtual environment. But it is not required.

[zifeo]

@DavidVujic Thanks for getting back, I suppose this could be solved by taking advantage of poetry dependency group? That might be handy to integrate into the plugin somehow (e.g. change env, and it syncs the deps).