Question about the

Address(project/src/python/app1/cli/main.py:cli)

object. Are the following statements true? * The part to the left of the colon is always a path to a file relative from the top of the repo. * The part to the right is the name of the target that has the file as a source. * If no target is listed, then nothing owns that file. * When a file has no owner, then

pants

goals using targets will not be able to act on that file.

1. Yes, this is true. It’s the

spec_path

, i.e. the path to the directory with the BUILD file. 2. it’s the

name='foo'

field from the BUILD file. If you leave off

name='foo'

, then it defaults to the directory name 3. That’s correct 4. That’s correct. Some goals like

count-loc

don’t need targets, but most do.

how are two targets with the same name in different projects differentiated?

An address ==

spec_path

(left side of colon) +

target_name

(right side of colon) The

name

field is enforced to be unique in each directory, which ensures that each address is unique

aah.. So if I have targets

.../python/db:mysql

and

.../python/db/rds:mysql

and they both source the same file,

.../python/db/rds/constants.py

, then that's when the

../

becomes important? Is this how the

Address

objects look for this scenario? *

Address(.../python/db/rds/constants.py:../mysql)

*

Address(.../python/db/rds/constants.py:mysql)

what are the full addresses here?

replace

...

with

project/src

Okay, so you have

project/src/python/db/rds/constants.py:../mysql

and

project/src/python/db/rds/constants.py:mysql

, right? This would imply that you have a BUILD file at

../python/db/rds

and one at

../python/db

. Both BUILD files have targets with

name='mysql'

. Does that sound right?

yes

Cool. So, what is the

sources

field for both of those targets? It sounds like the one in

project/src/python/db/rds

is using recursive globs like

**/*.py

/

seem to used to represent filesystem structure but are also used for namespace structure. Still trying to articulate the question I am curious to answer.

Does recursive or explicit declaration make a difference for Address()?

The recursive part only changes the way it’s represented for a “file” address.

project/src/python/db/rds/constants.py:../mysql

means you have a file named

rds/constants.py

. Its metadata is coming from the parent directory, in a target with

name='mysql'

, specifically its metadata is coming from

project/src/python/db:mysql

The question I know I have is "Should pants v2 say explicitly that

os.path.sep

characters are illegal in target names?"

I think so, because it’s really confusing how we now use them with file addresses. We didn’t have “file” addresses before Stu reached that same conclusion. We’re thinking of cherry-picking a deprecation into 1.30, then removing from 2.0

💡 So

spec_path

and

target

are combined to make the fully qualified target name. (

PurePath(spec_path).parent + target

then replace the right most

/

with a

:

)

So spec_path and target are combined to make the fully qualified target name.

Yes, that’s correct. And I guess I mispoke about what

spec_path

means… For a traditional (aka “base”) address, which is all there was in v1: -

spec_path

== path to the directory of BUILD file -

name

== the

name

field of the target for a “file” address: -

spec_path

== the literal file name -

name

== the original target’s name where the metadata is coming from, possibly including

../

if it’s in a parent directory Sorry, this is super confusing and imo the most confusing part of Pants. We spent a lot of time trying to figure this all out, and ended up going with it because making files the “atomic unit” of Pants was crucial to things like dep inference working well. But it’s still confusing, even if worth it

No apology necessary.

https://pantsbuild.slack.com/archives/C046T6T9U/p1604697541225400?thread_ts=1604696523.224700&cid=C046T6T9U correct: the same file can be owned by multiple targets, and they might have different metadata