Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

yeah - sorry.  you would not believe,  or you might, the grief I got from random channels after Dean died

<@U04S45AHA>: i'm worried about the "no BUILD files" for go decision being treated as precent... i'm worried that we're opting into synchronously parsing N different types of files in order to run `./pants list ::`

i'm fine with it asynchronously... ie, post server

We have a manual buildgen.go task, that is all

It _could_ be installed as a 1st task and automagically materialize BUILDs in memeory

ok. i think <@U09KGJ23Y> might have gotten the wrong impression then

<@U04S45AHA>: er, yea... but then `list` would need to depend on something that gens build files first?

er, yea maybe. not sure tasks should be doing that, but

i mean, remember that we want to kill synthetic targets for the engine refactor?

Iff someone wanted this, yes, they'd install a task that always ran 1st

and pants does not have a way to express always run 1st yet

so it would require both will and new code in pants itself to make this a sane thing to assert about a task install

No - we don;t want to kill synthetic targets - that's shorthand language

We don;t want targets added to the graph after tasks start to run

so "for now" the code might live in a task

right - so my point is, if someone wants targets inferred, pants needs to support some pre-all-tasks lifecycle

but then move out to a more generic graph initialization

basically, this is all muddyish, but implementing a buildgen plugin should not be