I was trying to take a stab at making the git sha/branch etc available to BUILD files as suggested at https://www.pantsbuild.org/docs/tagging-docker-images (I know about the spiffy

.pants.bootstrap

trick but though I would try anyway). I imagine to a user it would look like a handy object with properties for the sha, branch etc, and that it would make sense to leverage the existing

GitWorktree

I'm a little lost for what the 'shape' of this should be though with the existing precedents: • I don't think this is a new target or field... • I don't think it can be a

BuildFileAliases.object

(a "normal" python object) if it's going to reuse

GitWorktree

and it's engine integration •

ContextAwareObjectFactory

looked close but it's deprecated and/or there are zero left? •

ParseState

has some things like env() hard coded, but the necessity of that exceeded my ability to follow along

as the git data can be treated as static in terms of processing a request, I think it could work to simply populate a dataclass based object with the desired git data and expose it as a build file alias (second bullet option) — would require to always fetch the git data up-front rather than on demand which could’ve been nicer, but… 🤷 Might be a more clever alternative around if we put our minds to it tho..

hmm, so in the

BuildFileAliases

case it would be a "regular" dataclass object but take advantage of any of the nice async engine stuff? That is it would block to synchronously shell out at some point? I'm a little worried that would make everything slower but I suppose that is measurable? Or maybe a "regular class" that could lazily populate it's fields so you only pay the cost if you use it.

I think you overlooked:

would require to always fetch the git data up-front rather than on demand

which makes it less than ideal.. being that it would do the shell out to git always, regardless if being used or not.. I’ll see if I can come up with a better suggestion after having spent a little more time thinking about this.