Repository navigation
Add a stable version of x.py #76380
Description
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/rustcwill be on by defaultdebuginfo = 1by default whendebug = truewill not be reverted - if you have strong opinions about debuginfo I expect you already havedebug = falsefor 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.
Activity
jyn514 commentedon Sep 5, 2020
cc @infinity0 - would this address your concerns about the changes?
infinity0 commentedon Sep 5, 2020
@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.pydirectly - I'm doing that already anyway since Debian is encouraging us to use Python 3, and./x.pyhardcodes 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 commentedon Sep 5, 2020
Ooh, calling src/bootstrap/bootstrap.py directly sounds like a great idea, let's do that.
I'm a little undecided myself - my original idea was to have a wrapper that adds
--stage 2on 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 wayrustcknows about both 2015 and 2018 edition. That way there can't be conflicts because the parsing is in sync.infinity0 commentedon Sep 5, 2020
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 commentedon Sep 11, 2020
@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:
--set path.to.field=valuein x.py itself #76616x.py#76617x.py#76619I'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.