Hey everyone - how does pants' dependency inference handle ambiguous dependencies? Today we encountered a case where two

pex_binary

targets had

entry_point="foo/src/main.py"

and

entry_point="bar/src/main.py"

- each referring to a different

main.py

file in their projects. As long as there was just one of said binaries the PEX built just fine, presumably because there was just a single

main

module on the path. Pants inferred the right dependency and included it in the resulting pex file. However, as soon as a second project with a

main

module on the path appeared, pants no longer inferred the dependency and produced an empty PEX file - which we only noticed when trying to run the empty pex:

ImportError: No module named main

The surprising thing for me here was that

pants package

didn't fail. If I use an entry_point pointing at a file that doesn't exist at all,

pants package

rightfully fails with an error. But I was surprised that it didn't fail when the entry_point reference is ambiguous - the error appeared at runtime. The fix in our case was to add explicit

dependencies=["foo/src/main.py:lib"]

and

dependencies=["bar/src/main.py:lib"]

to the pex binary targets, and pants does the right thing. Is this expected? Is there some way to ensure that pants will not silently drop an inferred dependency when using a file path for the entry_point? (python 3.11, pants 2.18.1, macOS Sonoma on ARM)

oh, that's really interesting. can you open an issue for this? I think the issue comes from ambiguous dependency resolution at the target level. But we should be warning of ambiguous dependencies in that case https://github.com/pantsbuild/pants/blob/f717cdf2adef355e664c870042bb287c49d9e214/src/python/pants/backend/python/target_types_rules.py#L257

@careful-address-89803 It seems that a warning is indeed happening but as it's just a warning and the package happened in CI it went unnoticed. The order of events was

service_a

was created using a

main

entry point, no explicit dependencies declared. This worked.

service_b

was then added with a

main

entry point which resulted in a

No module named main

error without the explicit dependencies declared in

service_b

. This meant we declared explicit dependencies for

service_b

but we were unaware that this would affect

service_a

at this time. At a later date,

service_a

got rebuilt but now had an ambiguous entry point. Since it was built in CI the warning went unnoticed and the service was deployed with an empty pex. Is there a reason that an ambiguous entry point isn't an error here? The warning message even says that pants can't resolve the dependency safely and advises manual action be taken so it feels like it should make a bit of noise (or we should be able to make it make a bit of noise i.e. error)

Ah, I thought that the warning would be in the form of an error. But I confused that for unowned depedencies (although the default is to only warn on those). Although, that is the real problem here: we can't disambiguate and just return nothing, without consulting the unowned_dependency_behaviour. I'll ask if there's a reason, but I agree that we probably should.

Possibly we should have an option to turn those warnings into errors?

It's not triggered in this path, it's triggered in the dependency resolution for python sources. I've put together an MR here https://github.com/pantsbuild/pants/pull/20390 , I need to test it against the repro