hey folks wondering if you can help me out here, i have a BUILD file, that contains the following (databricks_job is a custom target) and im getting an ambiguous owner error

FAILURE: Owners for Resources(BuildFileAddress(src/adobe_mta/BUILD, config)) are ambiguous.  Found DatabricksJob(BuildFileAddress(src/adobe_mta/BUILD, job)) and 1 others: [PythonLibrary(BuildFileAddress(src/adobe_mta/BUILD, lib))]

Any advice?

Interesting rabbit hole! From the code, it looks like the function that raises this raises:

:raises: `AmbiguousOwnerError` if there is more than one viable exported owner target for a
             given transitive dependency.

Now, this would indicate that both

:lib

and

:job

are exported. I don’t see the code that makes

python_library

exported by default, but let’s assume it is for now. The code that raises that exception (https://github.com/blorente/pants/blob/998e4edbe31c64aeacac5142ad90433fce9a748b/src/python/pants/backend/python/tasks/setup_py.py#L187) iterates not only over the dependency chain, but also over the siblings to calculate potential owners (this function call https://github.com/blorente/pants/blob/master/src/python/pants/backend/python/tasks/setup_py.py#L243, which calls this method: https://github.com/blorente/pants/blob/998e4edbe31c64aeacac5142ad90433fce9a748b/src/python/pants/backend/python/tasks/setup_py.py#L73)

hmmmm good looking out, i'll dig into this source

It’s mostly to keep track myself, but yeah, might give you some clues maybe

yeah been swimming in that file for a minute now

Cool! Hope you find what you need 🙂

so i was able to achieve the results i need by switching https://github.com/pantsbuild/pants/blob/12711f2dc295fdda526cf9fab17146b87154ed08/src/python/pants/backend/python/tasks/setup_py.py#L699 to use

self.context.targets()

when

self._recursive

was set

It seems sane in this case, but I’m not the most qualified to think about all the ramifications, no too familiar with this part of the code. If you open a PR, I can add reviewers to it 🙂

thanks, will do

Added 🙂

Borja added me as reviewer. I don’t mind the code change, but don’t feel confident that I would catch subtle pitfalls that it may introduce, so will let a greyer beard chime-in 😄

yeah im definitely making some assumptions here. FWIW changing it locally seemed to cause no issues, but haven't really run it through its paces. However, seems reasonable that if recursive mode was on, it would package all those things up anyway

I'm a little surprised at this error - it implies that

:lib

and

:job

are both candidates to be the owner of

:config

, but AFAIK an owner has to be exported (that is, has to have a

provides=

clause), and neither of those do in your example. Did you elide those out of the example? I assume you were running

./pants setup-py [target]

?

yes they were elided. the

:job

gets a summy setup-py as its not really a python library. The PR i have outstanding allows us to stop subclassing the job as a library and still trigger dependent libs' build and publish steps