Am I correct in understanding/thinking that I can'...
# general
Am I correct in understanding/thinking that I can't generate `setup_py`'s
argument from a plugin since
appears to be a direct alias for
, which has assertions that argument is being provided?
My use case is I'd like to be able to read in that value from a file so I can DRY up project configuration. I need to be able to separately read in that value from another script, hence the separate file
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 ( An example of the hack can be read here: 1. Hack target to own file name will be read from: 2. Hack dependency wiring / target generation in a macro:[…]4 3. Registering the Hack target and Hack macro: a. b. 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 😂
Thanks, I'll see if that works out
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.