The second issue I'm seeing is with

pylint

. It seems pants'

concurrency_available

optimization is not doing a good job for my use case. When I don't have caching, the slower requirements building for the slowest batches delay the start of pylint for them enough for other small processes to finish. When they do start there is a lot of free concurency and the slowest batches use it effectively. With caching, all the requirement building is retrieved quickly from cache while the small batches are linting, so the big lint batches keep going with very low parallelism allowed (and they seem to miss the preemting window to be restarted with more concurrency available), so they just run for a lot longer and the CPUs are under utilized leading to an overall slower resolution despite the cache. I'm probably going to set lint batch size to some huge number above the file count (and rely on cache to retrieve the combined requirements pex) so the only lint task can take all the concurrency, but coming here to ask if there is a better approach to this?