so you might check whether you have multiple provi...
# general
w
so you might check whether you have multiple provides clauses in the graph you are publishing
f
I thought of that, but a) no, this is the only
provides
clause in the whole repo afaik, b) it seems like in that case the error would be
AmbiguousOwnerError
, instead of
NoOwnerError
w
does
./pants paths thing/I/want/a/wheel/for an/internal/python_library/target/I/depend:on
show you a path between them?
f
yup:
[thing/I/want/a/wheel/for , an/internal/python_library/target/I/depend:on]
it’s a direct dep
it would have to, right? otherwise why would pants be looking at
an/internal/python_library/target/I/depend:on
when trying to run setup-py on
thing/I/want/a/wheel/for
?
w
if it were an alias
f
ah, ok
w
you've said it isn't, but just confirming.
f
I tried pdb-ing through the pants code, and it seemed like actually maybe I need
thing/I/want/a/wheel/for
to be a parent in the directory/package hierarchy of
an/internal/python_library/target/I/depend:on
. like the latter would actually have to be
thing/I/want/a/wheel/for/an/internal/python_library/target/I/depend:on
. but I’m not sure I understand exactly what’s going on
w
would be good to file an issue about this, but you'll need to give a pretty detailed overview of the graph in order for anyone to get a repro.
mm, yea, could be.
yea, i forgot about that bit.
f
ok, I’ll poke around with that last hunch and if not I’ll try and get a minimal repro and file an issue
sorry to revive this — so, I made a top-level wheel package that includes my other library target in its
dependencies
. now the wheel builds, but none of the code ends up actually making it into the wheel? like the wheel just consists of a single
__init__.py
file
in general, the
setup-py
goal should include code from transitive deps, not just the direct dep of the python_library that’s being `setup-py`d, right?
w
yes. would suggest filing that ticket with an explanation of the layout at this point