Option values read from @files don't invalidate when the file changes #10360
Comments
stuhood
changed the title
|
So, I think that a plan here is:
|
|
I like it. V2-ification of the options system. However, this is a really big undertaking, so we should double check that this is a 2.0 priority. cc @benjyw. Is this only a broken window when pantsd is used? |
|
It is, but it's a big one. We could however just not support |
To confirm, something like |
|
Yea... that and possibly the It has a slight impact on performance, because we re-parse all config files for each run, and validate all option values rather than having them memoized... the engine would make that easy. |
|
FWIW, the |
### Problem #11536 moves from using POSIX-level replacement of the `stdio` file descriptors `{0, 1, 2}`, to replacing `sys.std*` with a thread-local implementation. Unfortunately, Python `subprocess`/`Popen` APIs hardcode `{0, 1, 2}` rather than actually inspecting `sys.std*.fileno()`, and so usages of those APIs that use `std*=None` (i.e. "inherit" mode), will inherit intentionally dead/closed file handles under `pantsd`. PEX uses inherit mode when spawning `pip` (in order to pass through `stderr` to the parent process), and this runs afoul of the above behavior. Pants has used PEX as a library for a very long time, but 95% of usecases have now migrated to using PEX as a binary, with wrappers exposed via the `@rule` API. The `PluginResolver` that Pants uses to resolve its own code is the last usage of PEX as a library. ### Solution In a series of commits, introduce a "bootstrap" `Scheduler` that is able to resolve plugins after an `OptionsBootstrapper` has been created, but before creating the `BuildConfiguration` (which contains plugin information). ### Result Although Pants has some stray references to PEX APIs, it no longer uses PEX as a library to resolve dependencies. #11536 and #7654 are unblocked. In future, if the options required to construct a minimal scheduler can be further pruned, the bootstrap `Scheduler` might also be able to be used to create the `OptionsBootstrapper`, which would allow for addressing #10360.
Any* option's value can be read from a file, by using
@path/to/fileas the value.A subsystem instance that has such an option is not invalidated when the contents of the file change, so changing the file and then rerunning pants doesn't apply the new value, until you restart pantsd.
fromfile=False.The text was updated successfully, but these errors were encountered: