Is there a good way to disable cbindgen while running tests so I can get decent error messages from cargo instead the very generic CbindgenErrors?

actually this is better https://pantsbuild.slack.com/archives/C0D7TNJHL/p1561585109121100

@witty-crayon-22786 @average-vr-56795 @early-needle-54791 wrt platforms in v2 -- i was under the impression that "target" vs "host" platforms only need to be differentiated if you are running a cross compiler (otherwise, you just need the "target" platform). this is something i believe bazel supports, but i think it would be a great simplification to avoid cross compiling, both in concept and implementation. my concern is that cross compilation would be a significant amount of effort to support, on top of the existing difficulty (which we've now managed) of compiling for the same platform, especially if people want to choose which compiler to use (see the comment i left on the doc at https://docs.google.com/document/d/1AWIvRRGzmE3q5IXiRCqvLPCo0BkqX_9y4F9B0KV_9h8/edit?disco=AAAADE1EQ5U). if the native backend tasks were converted to v2 right now, it would immediately work to compile things on a linux remote execution platform if pants was invoked from an osx machine, because: (1) pants is provided

Platform.linux

as a root input (2) pants resolves the appropriate binary tools for the linux platform (this already works) (3) pants constructs the snapshot for linux from those tools (this also already works, it's just not made into a snapshot because the tasks are still v1, because i was waiting for local process execution caching) (4) pants sends over the snapshot to the remote execution backend and receives the output (remote execution is known to work) this could be done without introducing a

PlatformSpecificExecuteProcessRequest

, and something like speculation could be implemented by instead just injecting the appropriate

Platform

parameter into the rule subgraph that ends up triggering the execution (because we already have a rule subgraph that does platform-specific logic in native_toolchain.py). it's true we then need to have a way to communicate to rust whether to execute the process locally or remotely, so maybe either a field on

ExecuteProcessRequest

or a separate object might work for that, but the identity of the injected

Platform

param is exactly what distinguishes the appropriate subgraphs in the native backend right now. i'm concerned when i see the

yield Get(PlatformSpecificBinary, ...)

in the doc because the native backend already does this exactly, without having to introduce new syntax or classes, or having to write code that knows anything about platforms except where it differs (which the native backend has already figured out). i spent some time when building the self-bootstrapping native backend to represent the intricacies of what's actually used when people run a compile from the compilers their package manager installs so that it could work immediately on all supported platforms. that time was spent first building on @happy-kitchen-89482's work on

BinaryToolBase

and

BinaryTool

to make it more injectable and extensible, and then adding lots of very basic descriptions of things like

Compiler

,

CCompiler

,

CppCompiler

,

CppToolchain

in https://github.com/pantsbuild/pants/blob/847dbe46f4d64635c23d2146d36f2642f0bd7918/src/python/pants/backend/native/config/environment.py#L22 (and there's some moderately-complex but really-useful logic added in that file with

_ExtensibleAlgebraic

and decorators to make this all really composable). i think that structure offers quite a lot to build off of. in the case of speculation, i don't think we need to have a "target" and "host" platform, because we can simply make sure we inject the appropriate

Platform

parameter at the start, as described above. i would really like the work we're doing with speculation to align with the existing logic. if we want a concrete example of platform-specific logic (since the jvm backend doesn't provide that), the native backend is very small and highly decoupled from other subsystems by design, and was written precisely to be injectable in this fashion. i can't edit the doc and comments can be ignored, hence the slack message

(coming into this with basically no context, but Bazel does have a distinction between “host”, “execution” and “target” platform: host is where bazel is running, execution is where build actions execute, and target is where the build output is intended to run. this captures the situation of running bazel on a mac, executing remotely on linux machines, building a windows binary, as one example)

context is https://github.com/pantsbuild/pants/issues/7735 and https://docs.google.com/document/d/1AWIvRRGzmE3q5IXiRCqvLPCo0BkqX_9y4F9B0KV_9h8/edit?usp=sharing

comments there would be appreciated

will respond to the above later this afternoon.

re: getting a description for `@union`: feel free to change the API however you want

yeah I wonder if it might be good in general

to have a description look for the docstring if there's no defined description

i like the idea of using docstrings that feels really neat

so maybe nowhere should be using an attr called "description"?

If we only use docstring, then that means

description

could never be dynamically generated, right? Like we do here: https://github.com/pantsbuild/pants/blob/master/src/python/pants/backend/python/rules/resolve_requirements.py#L64 That seems like we might not want to take that feature away

meh. "constraints are freeing"

"guardrails let you drive faster"

if this is about the static rule graph then descriptions like that aren’t relevant

but: i don't think that dynamically creating

@unions

is likely to be common.

if this is about descriptions for live objects in the engine then yeah

and if it is dynamic you can always just assign to the

__doc__

attr

Untitled.py

@aloof-angle-91616: executing in parallel is not exactly the same as executing speculatively

yeah i was thinking about that

1) it would wait for the slower run to finish rather than cancelling it, 2) it doesn't allow wait for a timeout before starting the second request

probably better to put them in the same execution request kinda like the above snippet does with the output

yea, this is discussed on the ticket and in the doc

which it can do without knowing anything about the execute process requests in question

the "local vs remote" request part is the "PlatformSpecificBinary" bit from the doc