Hi all, it seems like resolves don't support a very basic workflow, and it might be a dealbreaker for my company. We have a repository of both libraries and services. The services may have conflicting dep version constraints. The libraries must be consumable by all services. If I use resolves... 1. I have to manually declare that each library must be added to every resolve in the repository 2. Then the unit tests for our library have to run for each resolve (and I have 20+ services, so our pipeline is 20x slower) In poetry, it behaves far more intuitively. Theres a venv per-module, so services can have conflicting dep versions and libraries run unit tests against their own version constraints I created a sample repo to experiment with and to demonstrate the difficulty working with pants. I understand that resolves have some advantages over other approaches, but I would like to opt-out some features of resolves to have compatibility with poetry.

So the libraries themselves use 3rd party requirements, with version constraints, and the services have their own requirement constraints, and you manually ensure that they are mutually compatible?

> So presumably any conflicting version constraints in the services are for requirements not used by the libraries? Not necessarily, i.e.: • LibraryA: ◦

Flask>=1.0

very flexible minimum version • Service1: ◦ imports LibraryA ◦ imports and pins

Flask==2.0

to avoid a bug in newest versions • Service2: ◦ imports LibraryA ◦ imports and pins

Flask==2.1

for some other reason > you manually ensure that they are mutually compatible? Yes, poetry throws an error if the constraints were not compatible. For example, if I made a service try to use Flask lower than 1.0:

➜  poetry lock                  
Updating dependencies
Resolving dependencies... (0.1s)

Because service2 depends on libB (0.1.0) @ file:///Users/jasondamour/Workspace/pants-vs-poetry/Libraries/libB which depends on Flask (>=1.0), flask is required.
So, because service2 depends on flask (0.1.0), version solving failed.

Ah I see this https://github.com/pantsbuild/pants/issues/21194

The above example repo would work if Pants didn't know that LibraryA was in the repo, and treated it like an external dependency.

I'll take a look at your example repo

I really appreciate it!!

So the libraries are intended to be published?

In our real repo, we have ~10 libraries. Some are internal and some are published

Got it