I kind of miss documentation for all object types in the docs. There are only for subsystems, goals and top level target types. But if I look at

python_distribution

for instance, it mentions a type

PythonArtifact

for the

provides

field, but that type is not documented (online). Nor does it mention the alias for it, so I’d have to guess that it is

python_artifact

however, the docs use its synonym

setup_py

quite often too… so for new users, I think this is a frustrating thing to grok.

Agreed. Old style macros like python_requirements are also not documented, altho that will hopefully be fixed in the next month by target generation https://github.com/pantsbuild/pants/issues/7022 Objects would remain undocumented though. @happy-kitchen-89482 any insight on how hard it would be to wire those up to pants help-all?

Ah, of course, it is that output you use.. go figure. haha.

Yeah if that gets wired up, it becomes trivial to hook up to the docs :)

I'm not sure how hard, but it may not make sense to document it as floating under some generic "objects" category. Probably the right place for the

python_artifact

documentation is nested within the documentation page for

python_distribution

.

Actually it looks like the only "objects" left are `python_artifact`/`setup_py`, and `pants_version`/`get_buildroot()`. We don't document the latter two, and I see no reason

pants_version

would be useful I think we want to already kill

setup_py

in favor of the Target API. I doubt we would ever add an

object

in the future, now that we have the Target API So, rather than implementing this, maybe we should more into dropping

objects

I mean, I'm all for that

What does “dropping objects” imply?

Yeah, which you proposed in https://github.com/pantsbuild/pants/issues/12410 😉

LOL! RIght! 😛

Well that makes things easier! Turns out we didn't ever register

get_buildroot()

, I think as of changing to Pants 2. So it's not just undocumented, it's unused

setup_py

will be the only remaining

object

, which is blocked by having target generation so that we can deprecate the setup-py plugin hook in favor of more generic target generation

Are you referring to the SetupKwargsRequest -> SetupKwargs union? can’t that work any way, without setup_py.._

yep, exactly. Yeah actually I think you're right, it's still possible to support that plugin hook! It would be better to have proper target generation, but in the meantime