Add a stable version of x.py

[jyn514]

This came up in #76165 in response to the changes from #73964: currently the way to adapt to changes in x.py is 'learn about them because it broke something and change your workflow'. This is not ideal, especially for automated scripts. It would be great to have a separate, stable interface that doesn't change regardless of any changes to contributor defaults.

I imagine the defaults looking mostly, but not exactly, like the defaults prior to #73964:

• the default stage will go back to 2 for all subcommands
• src/rustc will be on by default
• debuginfo = 1 by default when debug = true will not be reverted - if you have strong opinions about debuginfo I expect you already have debug = false for a release build.

The setup I imagine is two different scripts that work on the same underlying codebase: x.py and bootstrap.py, where bootstrap.py is the stable version. Both will be 'facades' around the current src/bootstrap/bootstrap.py, and the logic of choosing defaults will still live in bootstrap.py and the rustbuild crate.

[jyn514]

cc @infinity0 - would this address your concerns about the changes?

[infinity0]

@jyn514 it sounds fine from my side, but others might find it confusing to have two top-level scripts with the same subcommand names and mostly-the-same CLI options. I'd be happy to call src/bootstrap/bootstrap.py directly - I'm doing that already anyway since Debian is encouraging us to use Python 3, and ./x.py hardcodes Python 2.

I also predict it would be more long-term work to wrap a stable API around unstable logic that selects convenient defaults, than wrapping unstable logic around a stable API, but perhaps you meant something slightly different from how I'm interpreting what you wrote.

[jyn514]

Ooh, calling src/bootstrap/bootstrap.py directly sounds like a great idea, let's do that.

I also predict it would be more long-term work to wrap a stable API around unstable logic that selects convenient defaults, than wrapping unstable logic around a stable API, but perhaps you meant something slightly different from how I'm interpreting what you wrote.

I'm a little undecided myself - my original idea was to have a wrapper that adds --stage 2 on top and such, but that means that it has to reimplement its own parsing to avoid conflicting with any flags the user passes. So the idea I had was to have the bootstrap binary know about both defaults, the way rustc knows about both 2015 and 2018 edition. That way there can't be conflicts because the parsing is in sync.

[infinity0]

has to reimplement its own parsing to avoid conflicting with any flags the user passes. So the idea I had was to have the bootstrap binary know about both defaults

Ah right, yes for some reason I thought bootstrap.py already did some parsing, but it looks like that's not the case. What you're saying makes sense now.

[jyn514]

@infinity0 I talked about this with @Mark-Simulacrum and we decided that maintaining a stable version of x.py in perpetuity would be too high of a maintenance burden; for instance, it wouldn't have allowed the changes in #76415.

As an alternative, I opened several other issues that should help with your use case:

• Allow --set path.to.field=value in x.py itself #76616
• Add a changelog to x.py #76617
• Add default configuration files for x.py #76619

I'd love to hear your opinions on those! But I don't think a stable x.py is ever going to be implemented, so closing this.