Cannot extend build directives within cargo

[epage]

Because of cargo:KEY=VALUE, it isn't safe to add cargo:error= (or any other directive) as it can be interpreted as a KEY/VALUE, blocking #10159.

[epage]

tl;dr we decided to extend the build directive syntax with cargo:: (maintaining compatibility on cargo: support). cargo:KEY=VALUE metadata syntax would move to something like cargo::metadata=KEY=VALUE. The name "metadata" was not fully settled on.

Ideally, cargo:KEY=VALUE would be changed to cargo:metadata=KEY=VALUE (name to be bikesheded) and we can extend as needed.

How to do it

• Change it on an edition boundary
  • A directive could opt-in to the style
    • We'd need "begin" and "end"s to allow composing with third-party dependencies
  • Provide an env variable with the package.edition for what directive syntax is accepted by default
    • There are target-specific editions but the build script is tied to the package and not the target
• Hack in a new namespace, say cargo:: instead of cargo:
  • For cargo:KEY=VALUE, we'd get :KEY=VALUE which seems a corner case enough that we'd consider this a minor incompatibility instead of a major incompatibility
  • Update all documentation to use :: with a note that : exists for compatiblity purposes with support for some directives

In the cargo team meeting we feel like cargo:: is a relatively simple solution with little documentation impact (new syntax, not concepts or interactions). We can always add directive versioning in the future within the syntax we have. We do not see any other compatibility traps within this syntax.

[XaurDesu]

Could i take a look into this? Currently learning rust and it is marked as 'help wanted'

[epage]

Sure. Feel free to message me on Zulip if you have questions

[XaurDesu]

@rustbot claim

[Rustin170506]

@rustbot claim

Since there was no progress for a long time, I wanted to try to implement it.

[Rustin170506]

• Change it on an edition boundary

  • A directive could opt-in to the style

    • We'd need "begin" and "end"s to allow composing with third-party dependencies

  • Provide an env variable with the package.edition for what directive syntax is accepted by default

    • There are target-specific editions but the build script is tied to the package and not the target

@epage Could you explain a bit about change it on an edition boundary? Did you mean we use cargo: in edition 2021, and use cargo:: in the next edition?

[XaurDesu]

@rustbot claim

Since there was no progress for a long time, I wanted to try to implement it.

Go ahead, i wanted to help here but college brought me down. As @epage told me, please take a look into #11312 , because it points out to a bunch of the places that must be changed for this request.

EDIT: i copied the wrong pull request, sorry for that.

[epage]

@hi-rustin sorry if this wasn't clear but all of those notes were a summary of the discussion. We ended up deciding this will not need an edition boundary as we ended up preferring the "Hack in a new namespace, say cargo:: instead of cargo:" route (those were meant to be alternatives, not parts of the same solution).

[XaurDesu]

@hi-rustin sorry if this wasn't clear but all of those notes were a summary of the discussion. We ended up deciding this will not need an edition boundary as we ended up preferring the "Hack in a new namespace, say cargo:: instead of cargo:" route (those were meant to be alternatives, not parts of the same solution).

Would it be feasible/desirable to make this it's own issue? given that, according to you:

In the cargo team meeting we feel like cargo:: is a relatively simple solution with little documentation impact (new syntax, not concepts or interactions). We can always add directive versioning in the future within the syntax we have. We do not see any other compatibility traps within this syntax.

This could probably be added to the issue list. I might be wrong however, since i'm still fairly new to the codebase. What do you think @epage ?

[epage]

Its not quite clear to me what we would want another issue for or what you mean by "added to the issue list".

This issue would be resolved by the cargo:::. We could have an issue for directive versioning support but I personally wouldn't bother creating one. If we actually run into that, we can reference this issue for context. I see it as unlikely and adding noise to our already large backlog.

[XaurDesu]

Alright then, makes sense.

[Rustin170506]

@hi-rustin sorry if this wasn't clear but all of those notes were a summary of the discussion. We ended up deciding this will not need an edition boundary as we ended up preferring the "Hack in a new namespace, say cargo:: instead of cargo:" route (those were meant to be alternatives, not parts of the same solution).

Got it. Thanks! I will give it a try recently.