How to deal with conflicting dependencies across bases in the root pyproject.toml / workspace setup?

[hamannju]

Hi,

I have an issue in my polylith structure. It is mostly modeled after the polylith-example-uv repository. I currently have quite a few components and also a base that uses FastAPI and SQLAlchemy >2.0.0. However, now I want to integrate Apache Airflow 3 + DAGs into my repository and re-use my components in the DAGs but Airflow >3.0.0 currently has a dependency on SQLAlchemy <2.0.0 which leads to a conflict in my root-level pyproject.toml.

What is the recommended approach for dealing with this? Have I misunderstood something about the structure? I currently have all components and bases added to the root pyproject.toml to have a dev environment with everything available.

I was thinking of refactoring this so that only the project-level pyproject.toml files have the components, bases, and their dependencies in them so that there would not be two bases that are in conflict with one another.

What would be the recommended / best practice of dealing with this issue?

[DavidVujic]

Hi @hamannju,

Yes, having all bricks defined in the top project (as recommended) requires the dependencies to be compatible. In this case, you could choose to include one of the two and have individual lock files for the projects using the different bricks with the different dependencies. I don't think uv would allow one lock file with two versions.

If an upgrade is not too much work, I would recommend to just migrate the code that depends on the older version. If it is a bigger effort, then I would do as I suggest above with the lock files and with not including all bricks in the top folder. The downside is that your virtual environment will only contain one of the two.