curved-manchester-66006
03/30/2023, 1:30 PM.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 alongcurved-television-6568
03/30/2023, 1:35 PMenv()
and friends to avoid that complexity)curved-manchester-66006
03/30/2023, 2:20 PMBuildFileAliases
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.curved-television-6568
03/30/2023, 3:15 PMwould require to always fetch the git data up-front rather than on demandwhich 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.