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

Pants

as it stands, their work can't be cached in the daemon

and making a new subclass of the AddressMapper would allow them to use the engine, but where the code is currently running, it will not occur inside the daemon

the daemon only handles the initial creation of the graph

post fork, the engine is still used to expand the BuildGraph, but you're in a new process, and so the work isn't cached

at least for this part, they are only looking at what current targets own. I think the more general problem of looking at what targets at different points in time owned may or may not be cacheable depending

it is definitely cacheable. it's just a question of how to adapt the Task to a model where this needs to happen pre-fork

so the daemon forks before work happens, so we’d use the cache from pre-fork, but not update

"Tasks that change the roots in the context" are a third class, to go along with "frontend" tasks and "backend" tasks

What happens pre-fork? Could you point me to a few steps in the lifecycle there?

<@U066LC126>: in a nutshell, we parse the spec roots from the command line, and inject them to a LegacyBuildGraph. then we fork: <https://github.com/pantsbuild/pants/blob/master/src/python/pants/bin/goal_runner.py#L81-L96> . Kris knows more

... that line might be too late to see where the cached graph is coming from actually.

this is basically the pre-fork bit: <https://github.com/pantsbuild/pants/blob/master/src/python/pants/pantsd/service/pailgun_service.py#L52-L72>

via <https://github.com/pantsbuild/pants/blob/master/src/python/pants/pantsd/pailgun_server.py#L51-L85>

where the runner class is <https://github.com/pantsbuild/pants/blob/master/src/python/pants/bin/daemon_pants_runner.py#L58>

so anything that happens before runner.run() is pre-fork

woot! <https://github.com/facebook/watchman/issues/305#issuecomment-233768677>

<@U066LC126>: followup from the snapshot discussion on your review: i feel pretty strongly that `Snapshot` as a core intrinsic is going to be important

perhaps even that "getting a Snapshot of a glob" rather than "getting Files for a glob" is the most important operation

for one thing, it seems like it's potentially much more efficient (EDIT: ...and thus relevant for this quarter perhaps?)

for another, it seems like it might align better with a move to scoot over time.