https://pantsbuild.org/ logo
Join Slack
Powered by
I think I'm running into some confusing behavior w...
# general
h
I think I'm running into some confusing behavior with 
paths
. I have two dockerfiles with pex binaries that I know are independent of one another. But somehow 
paths
is saying that they are dependent. Here's a quick sketch of what I have
Copy code
> src
  > foo
    A.py
    B.py
    Dockerfile
  > bar
    C.py
    D.py
    Dockerfile
A.py
depends on 
B.py
and goes into 
foo/Dockerfile
as a pex. 
C.py
depends on 
D.py
and 
B.py
and goes into 
bar/Dockerfile
. When I do 
paths
from 
bar/Dockerfile
to 
A.py
, I would expect no link, but somehow I am getting one through the Dockerfiles. Do target tags mess with the dependency tree at all?
Well, it's not Dockerfile related, because I can confirm things are getting picked up when I inspect the packaged pex file
h
Do target tags mess with the dependency tree at all?
No, they are not involved in dependency inference
The 
dependees
and 
dependencies
goals might be helpful to confirm where the bad dep is getting introduced
h
When I do 
./pants dependencies --transitive C.py
, I see 
A.py
in the output. When I do 
./pants paths --from=bar/C.py --to=foo/A.py
, I get
Copy code
bar/C.py:sources
foo/foo-docker
foo/foo-pex
foo/A.py:sources
Am I to read that as it's thinking there is a dependency through the Docker image?
h
Maybe try 
./pants dependees foo/foo-docker
h
As I would expect, the docker image target has no dependees reported
I think that's what is happening. Somehow my python module thinks it is dependent on the Dockerfile from another directory.
I'm wondering if this has to do with how I named the docker_image target. I have it named the same as the folder name. So it looks like
Copy code
docker_image(name="foo")
Cause isn't there some default behavior target naming and the parent directory of the BUILD file?
Funny enough, when I delete the 
docker_image
target (or rename it), I get a ResolveError saying 
foo
can't be found.
h
you're not using explicit 
dependencies
?
h
okay I figured it
When I added 
B.py
as a dependency, I needed to say 
B.py:sources
Then I see the behavior I expect where there is no link between 
C.py
and 
A.py
I think that's kind of odd and it seems like when I don't say 
B.py:sources
, it's expecting to find the default name which would be 
B.py:foo
But 
foo
is the name of my 
docker_image
target because of how I want it to show up in our registry
h
ahhh, why did you need to add an explicit dep?
h
So then it goes down that path
Because we do some dynamic things at runtime
But this is interesting. I'm wondering if there's a better method of determining what target something belongs to rather than assuming the name from the parent directory.
h
fwiw, I've pushed in the past to get rid of the default 
name
and have tailor use defaults like 
python_sources(name="lib")
. I think it makes things more predictable
h
Yeah, anywhere (e.g. open ticket) I can +1 or share what I just learned here?
h
sharing your thoughts on https://github.com/pantsbuild/pants/issues/12286 would be great!
c
Aside, there's a repository field to override the image name so it is not a hard link with the docker image target name.
👍 1
h
oh, great to know!
Open in Slack
PreviousNext
Powered by