Am I correct in understanding/thinking that I can't generate `setup_py`'s

name

argument from a plugin since

setup_py

appears to be a direct alias for

PythonArtifact.__init__

, which has assertions that argument is being provided?

So, you're treading into an interesting and dangerous area that is not (well?) supported yet. The fundamental gotcha to contend with is Pants must be aware of the file the name comes from so it can change-track that file to know when it needs to re-run rules that consume the name value. In spirit you need a rule that generates a python_distribution target - or some of its fields. In practice, we have no such 1st class facility for generating target metadata from (non-BUILD) files and we use a hack via macros (https://www.pantsbuild.org/docs/macros). An example of the hack can be read here: 1. Hack target to own file name will be read from: https://github.com/pantsbuild/pants/blob/a2e7ecf55f78d0611ff43c7db8d6a43cb570c86b/src/python/pants/backend/python/target_types.py#L650-L653 2. Hack dependency wiring / target generation in a macro: https://github.com/pantsbuild/pants/blob/dee363930f4d4f37438695128e082a1266253d26/src/python/pants/backend/python/macros/python_requirements.py#[…]4 3. Registering the Hack target and Hack macro: a. https://github.com/pantsbuild/pants/blob/311419b50a36743c284e27af20053fb7ae9e0925/src/python/pants/backend/python/register.py#L44-L52 b. https://github.com/pantsbuild/pants/blob/311419b50a36743c284e27af20053fb7ae9e0925/src/python/pants/backend/python/register.py#L76-L82 There is alot to digest in the hack, so fire away if you have questions after absorbing all that.

Seems to be a pattern in the things I'm trying to do 😂

If your usage pattern involves tools outside Pants control interacting with / working along side Pants then it will continue to be a theme I think. We have assumed we're in control for the most part. It's good to have use cases like yours push on these assumptions.

This is a script local to the repo, so it could be pulled into a pants goal - the purpose of the script is to generate a new version, version the changelog, and then git-tag. It could easily be a "codegen" plugin

Ah, yeah - this is a common need. We have not tried to wade in here yet since folks have a fair bit of variation in how they handle publishing. In Pants v1 we did weigh in for the jvm. That supported: 1. Auto-publish: i.e.: run

./pants publish ::

without fear - only packages (jars) not already published were published. 2. Auto-changelog: This was generated via git and was based on the changes from the last publish (if any, else beginning of history) to now. 3. Auto-version bump: The patch level was incremented. By default the goal was interactive and forced you to accept the changelog and patch version bump. This gave you a chance to change the version bump using a cli option if a minor or major bump was appropriate. It would have been top-notch to support automatic semver with analysis of the public API changes, but we never got there.