Stu Hood

Results 228 comments of Stu Hood

I wrote a very long comment, and then decided to turn it into a doc instead: https://docs.google.com/document/d/1AWIvRRGzmE3q5IXiRCqvLPCo0BkqX_9y4F9B0KV_9h8/edit?usp=sharing (comment access via a `pants-devel@` account).

I've opened #8090 to represent an "MVP" for platform-awareness, where we at least don't accidentally remote something that we cannot.

A common thread between #9760, #10352, the [Multi-Platform Speculation](https://docs.google.com/document/d/1hS0n6vp-hBxy4Xo-q9QA_elofzQtOubjfN4nSeIgp90/edit#) doc, and recent issues with discovering a bootstrap python to use: we need a native facility for per-host/platform/environment configuration. The description...

This is related to cross-platform speculation (https://docs.google.com/document/d/1hS0n6vp-hBxy4Xo-q9QA_elofzQtOubjfN4nSeIgp90/edit#), but also to adding native support for executing processes inside of docker containers (which is a form of cross-building). EDIT: Now covered by...

https://github.com/pantsbuild/pants/issues/13451#issuecomment-956863674 makes the good point that the `interpreter_search_path` is also potentially platform specific.

> Following up re [#13451 (comment)](https://github.com/pantsbuild/pants/issues/13451#issuecomment-956863674), if we currently have a repo with linux and macos developers how should we handle `interpreter_search_paths`? Make everyone use pyenv? That is one good...

#11148 and #13682 cover cross-building using remote execution, and docker (respectively).

> Rename subsystem: > > https://github.com/pantsbuild/pants/blob/cdf21fc69954aec999ed57ed988bf67a31148bf9/src/python/pants/core/util_rules/environments.py#L44 So... how would we feel about keeping environments in the `preview` state for at least one stable release, with a tracking ticket that covers...

> Should the `environment` field also be preview, you think? Especially if we aren't 100% certain on the semantics for `python_source` targets having environments specified, and transitive deps validation. No,...

This relates to #11688, which suggests that one option would be to reify async tasks that we _know_ must exit (rather than necessarily assuming that everything on the executor must...