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

Pants

```4sq [~]:
[!40771]$ python -m timeit -n 1000 "for x in xrange(1, 100000): pass"
1000 loops, best of 3: 1.46 msec per loop

4sq [~]:
[!40772]$ python -m timeit -n 1000 "all(xrange(1, 100000))"
1000 loops, best of 3: 796 usec per loop```

However I'm still of the opinion that, in the absence of significant perf justifications, side-effecting iteration should happen in a `for` loop

Not in an expression whose value is thrown away

so you’d prefer I kill the `all()` usage here or dont care?

seems to be splitting hairs at this point

I'd prefer that method not be a side-effecting generator

If I called that method, I would _not_ be expecting to have to exhaust it by hand for its side effects to be done

I wouldn't even necessarily expect it to return anything

<@U054MQUPL>: `dtruss` on the daemon as a request is arriving is interesting. looks like it ends up reparsing pants.ini

guess that makes sense, because we haven't moved that into the engine yet?

<@U053HNE90>: it isn't a side-effecting generator... i was just copying the existing BuildGraph.inject_specs API

In that case, it doesn't need the `all()` or a `for` ?

<@U053HNE90>: from the perspective of an API consumer, there isn't a way to know what is behind the generator

i don't think that's an `:API public:` method though... could certainly switch it away from a generator.

Or we could note that it returns a generator, but the side effects have already occurred before the first yield

that's not the case for the other BuildGraph impl, iirc.

That way if you care about the perf implications of not exhausting generators unnecessarily (or creating lists behind the scenes for you that will immediately be thrown away), you can use it naively

will likely be a moot point soon: i think we're going to move to a factory function to instantiate the graph

<@U054MQUPL>: So I'm fairly indifferent here except that I think the API should be better, and a method like that should explicitly not require exhaustion for its side effects.  For now, I'd be happy with a comment and either `all()` or `for ...`

Well, it explicitly _should_ or _should not_, depending on whether the "should not" really matters.  But it should be guaranteed one way or the other

Feel free to do with that issue what you will