Ed Schouten

Hey @katre, Even though that proposal you linked looks interesting, I don’t really understand how it’s relevant in this context. In this specific case we want to force toolchain resolution...

> This can be solved by defining two toolchain_type for the toolchain. `toolchain_type(name="tool")` and `toolchain_type(name="runtime")`. We already do this for Python and Java. Are those the toolchains that intentionally have...

@BoleynSu ``` runtime_rule(name="jq_amd64", binary = "@jq_linux_amd64") toolchain(name="jq_amd64", toolchain = "jq_amd64", target_compatible_with = linux_amd64, toolchain_type=runtime) ``` The way `toolchain()` is called, this is basically saying: "Behold! Here is a copy of...

Friendly ping!

Nitpicking: COULD is not part of RFC 2119. https://datatracker.ietf.org/doc/html/rfc2119 If we were to make a change along these lines, we should use MAY instead.

Use an enum where 0 indicates it’s writable? Or place it in a nested message. If the message is absent, clients may assume legacy behaviour where the CAS is writable.

Hey Rod, > Have a read through https://github.com/multiformats/cid/pull/49 and you'll get a sense for the kinds of things people want out of a possible CIDv2. Particularly the last comment where...

For Protobuf’s binary format it is 100% safe to upgrade a singular field to a repeated one. In fact, a repeated field that only has a single element is encoded...

I think it looks good to go. But let’s give it a final round of discussion during the monthly gathering.

> So we cannot have tool_details being a singular struct in some requests and an array in others. Please see the discussion we had above, which specifically discusses the compatibility...