Hi, followup on https://github.com/pantsbuild/pants/pull/9334 that Stu recommended putting in Slack. That PR adds a new

targets()

entry point to

register.py

like this:

def targets():
    return [PythonBinary, PythonLibrary, PythonTests]

It leaves open the question of how do you register macros like

objects

and

context_aware_object_factories

. In a discussion with Stu, I was thinking something like this:

def macros():
  return {"objects": [O1, O2], "context_aware_object_factories": [CAOF1]

My reasoning is that macros are by definition an “advanced” concept. I would love for plugin authors to be able to register Targets without having to know about macros. Thoughts?

Is the question asking help choosing between?: 1. registration function per type (target, object, caof, ...) 2. registration function for target, then one for rest via dict 3. registration function for all via dict

The main question I’m trying to answer now is that we do go with a registration function

targets()

for Targets. It’s still open how to register macros. I would advocate

macros()

with a dict, but we could do

macros()

with a typed object like

Macros(objects=[], context_aware_object_factories=[])

or have

objects()

as an entrypoint, etc.

For v2 Targets or both?

Only v2 targets. V1 will still use

BuildFileAliases

unmodified

Hmm, that's confusing based on the words for an end user.

Hmm, that’s confusing based on the words for an end user.

How likely do we expect it to be that users write both V1 and V2 plugins? It’s confusing in a mixed codebase, indeed, but in a V2 only codebase you can ignore “build_file_aliases”

I think we can safely ignore v1 plugin authors for the purpose of this discussion, which is about v2 plugins specifically, I think?

I would hope we'd expect all v1 users to upgrade, so basically all of them.

By "ignore" I mean "provide an upgrade path", but I don't think we need direct backwards compatibility of registration logic

I'll be more clear. If I'm upgrading a v1 codebase, the

build_file_aliases

I have in my register.py implies those are the aliases that show up in BUILD files. Sure we can have docs that say - hey, in v2 we'll add aliases from

targets

too ... but as I said, confusing just based on the words in the register.py file.

Given a clean room, I think having a registrsation function per type would be best for clarity sake.

Agreed, this is the approach I took.

Given the non-cleanroom, not sure.

My thoughts on this is that plugin authors are super-users. Your typical Pants user at an org like Foursquare is unlikely to write a plugin or poke around

register.py

, although it is very likely that a team or individual at the org will write some plugins. So, I’m not as concerned as I normally would be with the possibility for confusion because the audience is small and more familiar with Pants I think it’s worth going with the approach that we’d develop in a clean room. V1 will be removed one day, whereas this endpoint will presumably exist for ever, so I’d rather that we do what is the cleanest approach, even if the migration path is more confusing

OK - it would be good to have the global namespace that is a BUILD file today in mind though and how you deal with that. Even the experts will need to know what's up there.

Can I register an old style “python_binary”: PythonBinary and a FieldsBasedPythonBinary with alias “python_binary” too? Is there a silent winner or a build configuration validation error?

That hasn’t yet been worked out. FWIT, I think that we should eagerly fail when that happens, which is possible because

build_configuration

stores both entries. One of my next sprints is providing a way to go from a V2 Target to V1 target. Meaning, in the case of both V2 and V1, we’ll want V2 to be the canonical symbol, and then it gets downcast to a V1 target. (If you aren’t using V2, you can keep your V1 target without changes)

K, sg

a slightly confusing thing about having lots of registration functions is that it is unclear that they all end up as aliases in BUILD files

the other thing that Eric and I briefly discussed is that end users are more likely to create macros than they are to create targets

I still disagree with this. I asked @clean-wolf-14674 to run a quick ripgrep experiment and Foursquare is using

targets

11x more than

objects

and

context_aware_object_factories

combined

It would be awesome not to speculate until we actually know what a macro even is in v2. We don't do we?

a slightly confusing thing about having lots of registration functions is that it is unclear that they all end up as aliases in BUILD files

Once

BuildFileAliases

is removed (because V1 is removed), we would only have the entry points:

rules()

,

targets()

, and

macros()

. No more

build_file_aliases()

,

global_subsystems()

, or

goals()

targets()

and

macros()

register symbols,

rules()

does not.

and

macros

would have both

objects

and

$something_that_can_create_more_than_one_target

?

Yes. See https://pantsbuild.slack.com/archives/C0D7TNJHL/p1584570241367400?thread_ts=1584569916.366900&cid=C0D7TNJHL. We don’t need to commit to any particular API for what

macros()

actually looks like, yet. But, the idea is that it has all the things used that behave like a macro

objects aren't macros, per-se... just bare symbols.

The other part of the old new target API was the build-file facing part that allowed inlining content for sharing which would eliminate the need for most objects and some macros. I haven't followed along enough to know if that's still in play.

The other part of the old new target API was the build-file facing part that allowed inlining content for sharing which would eliminate the need for most objects and some macros. I haven’t followed along enough to know if that’s still in play.

It presumably could be, but hasn’t received much attention. We are still using

Struct

fwit

to the extent that we can dodge the question of what

register.py

will look like "at the end", imo, let's do that

to the extent that we can dodge the question of what register.py will look like “at the end”, imo, let’s do that

We could punt on it and call it

targets2

for now. I’d rather call it

targets

, but even more I’d rather land this PR today so that I’m unblocked on the next PRs in this project. We could revisit later need be

examples we have internally are

create_python_tests

, which declares two targets: a python2 target and a python3 target (...and others for thrift and jdk11. the thrift case goes away based on the codegen API, i think. but tests are roots)

@happy-kitchen-89482 is

targets2

acceptable? There’s precedent with

backend_packages2

yep.

Why not just

targets

?

To avoid us committing to a particular end point. I still think

targets

is the way to go but just pushed a commit to call it

targets2

because this is easy for us to change back and this decision isn’t very important to the rest of the project

Fair enough