./pants

def get_pyenv_root():
    try:
        return subprocess.check_output(["pyenv", "root"]).decode().strip()
    except (OSError, subprocess.CalledProcessError):
        return None

-            [f"--ca-certs-path={certs_file}"], env={"PATH": None, "PYENV_ROOT": None, "HOME": None}
+            [f"--ca-certs-path={certs_file}"], env_inherit={"PATH", "PYENV_ROOT", "HOME"},

PantsEnvironment

WRAPPER_REQUIREMENTS

WRAPPER_SRCPATH

pants

pants.log

--stats-log

thread

open

StreamingWorkunitHandler.session()

StreamingWorkunitHandler

.session()

local_pants_runner.py

Here’s a rule of thumb for designing good Trio-style (“trionic”?) APIs: if you’re writing a reusable function, then you shouldn’t take a timeout= parameter, and instead let your caller worry about it. This has several advantages. First, it leaves the caller’s options open for deciding how they prefer to handle timeouts – for example, they might find it easier to work with absolute deadlines instead of relative timeouts. If they’re the ones calling into the cancellation machinery, then they get to pick, and you don’t have to worry about it. Second, and more importantly, this makes it easier for others to re-use your code. If you write a http_get function, and then I come along later and write a log_in_to_twitter function that needs to internally make several http_get calls, I don’t want to have to figure out how to configure the individual timeouts on each of those calls – and with Trio’s timeout system, it’s totally unnecessary.

Of course, this rule doesn’t apply to APIs that need to impose internal timeouts. For example, if you write a start_http_server function, then you probably should give your caller some way to configure timeouts on individual requests.

Here’s the rule: if it’s in the trio namespace, and you use await to call it, then it’s cancellable (see Checkpoints above). Cancellable means:

- If you try to call it when inside a cancelled scope, then it will raise Cancelled.

- If it blocks, and while it’s blocked then one of the scopes around it becomes cancelled, it will return early and raise Cancelled.

- Raising Cancelled means that the operation did not happen. If a Trio socket’s send method raises Cancelled, then no data was sent. If a Trio socket’s recv method raises Cancelled then no data was lost – it’s still sitting in the socket receive buffer waiting for you to call recv again. And so forth.

If a cancel scope becomes cancelled before entering its with block, the Cancelled exception will be raised at the first checkpoint inside the with block. This allows a CancelScope to be created in one task and passed to another, so that the first task can later cancel some work inside the second.

Cancel scopes are not reusable or reentrant; that is, each cancel scope can be used for at most one with block. (You’ll get a RuntimeError if you violate this rule.)

And now that we know where our cancel+schedule points are, there’s the question of how to effectively communicate this information to the user. We want some way to mark out a category of functions that might block or trigger a task switch, so that they’re clearly distinguished from functions that don’t do this. Wouldn’t it be nice if there were some Python feature, that naturally divided functions into two categories, and maybe put some sort of special syntactic marking on with the functions that can do weird things like block and task switch…? What a coincidence, that’s exactly how async functions work! Rule 4: in Trio, only the potentially blocking functions are async. So e.g. Event.wait() is async, but Event.set() is sync.

native.py

Externs.create_exception()

eval(code: &str)

py.eval(&format!("Exception(\"{}\")", msg)

msg

"

msg

"

\"

.chars()

String

session.product_request()

--dynamic-ui

The answer might be to make the "render the UI" flag a per-product_request method call flag, rather than a Session-level flag,

ExecutionRequest

ARCHFLAGS

SETTABLE_ENV_VARS

src/python/pants/core/util_rules/subprocess_environment.py

read_error_count: BTreeMap<String, usize>

remote_cache::CommandRunner

Mutex

CommandRunner

run()

Arc