@curved-television-6568 and @careful-address-89803 : Here is a first pass at allowing the python dep inference to use the new dependency rules feature to disambiguate possible deps.

<https://github.com/pantsbuild/pants/compare/main...cognifloyd:pants:py-infer-dep-rules|https://github.com/pantsbuild/pants/compare/main...cognifloyd:pants:py-infer-dep-rules>

Will have a look this weekend. My refactor was mostly to surface the inference decision-making to the debug goal. I remember most of the ambiguous detection happening inside of maybe_warn_of_ambiguous_dependency_inference. I'll have to read up on the dependency rules feature. One thought of further direction that occurs to me is that we may also want to hook into the code that looks for possible sources of a dependency (I think that's only for 3rd party at the moment, looking in other resolves)

Yeah. I wonder about surfacing info in the debug goal about targets that got filtered out based on dependency rules. My commit does not do that.

interesting (and 🤯 you typed this up on your phone!) I’ll take a closer look tonight. 🙂

Coming at this from a debug point of view, I think there are 2 distinct situations: 1. dep would be ambiguous, but visibility rules disambiguate 2. dep is findable, but visibility rules discard, resulting in Unowned I'm using those situations, and the ability to get the debug info, to guide my thinking on this. Depending on the ethos of Dependency Rules, there are a few places I see we could inject the filtering. I think this MR views it as way of refining the resolved Owners of an import. This does limit the actions it can do, really only to modifying the PythonModuleOwners by removing ambiguous owners and trying to identify an Unambiguous owner. We can slide this into

_get_imports_info

instead, for a similar result (like you indicated). I think a different view would be to view the dependency rules as culling the targets which could become Owners. We would then move the logic into the

Get(..., PythonModuleOwners)

or somewhere deeper in that. There is already some filtering done in

FirstPartyPythonModuleMapping.providers_for_module

based on the resolve. It's a bit different in that it either searches in one resolve or all of them, rather than actually culling the available mappings. This view doesn't readily offer debug information, but could be provided through something similar to the way 3rd party deps have suggestions for other resolves that contain them. I haven't actually dug into this part of the codebase, tho. A couple edge cases I can see: • need to discard unambiguous but blocked owners • explicit dep on blocked owner

opt 1. makes sense to me 🙂

I thought both of those situations would be results of dependency rules, I don't think we can have only one of them. Imagine the case where there are 2 deps, 1 allowed and 1 forbidden. To perform situation 1, we'd remove the forbidden dep and get the allowed dep. But if the allowed dep is deleted by the user, we should still disallow the forbidden dep and have no deps left. I'll have a look at the PR, probably over the weekend.