Open Ezrashaw opened 1 year ago
cc @jyn514 am I crazy about getting rid of Python from bootstrap?
I don't see the point in rewriting all this code. The main goal of https://github.com/rust-lang/rust/issues/94829 is so we don't make people deal with python before they start working on the repo; but half the scripts you mentioned are for CI only. What do we get from rewriting them?
I guess maintainability in a way. I mean, why is compiletest
not written in Python? It then makes sense to have the rustdoc
part of it written in the same language, possibly src/etc/htmldocck.py
could be rewritten and moved into compiletest
itself. I'm not saying that this is important, just that it's something that should happen at some point.
I don't think this is worth spending contributor time on. There are other ways people can get started contributing (https://rustc-dev-guide.rust-lang.org/#what-should-i-work-on).
I agree, I think it's just good to have this here as a long-term goal.
It's probably worthwhile to first step back and characterize the existing python that we have. I think only once it's clear what python actually can be rewritten should we actually discuss whether it should be rewritten.
e.g. those gdb and llvm scripts can't be rewritten in rust afaict.
Yeah, perhaps CI scripts as well might not be rewritable?
I do think there is some low-hanging fruit here which could have tangible benefits.
I have a rewrite of library/core/src/unicode/printable.py on another machine, moving it into the rest of the table generation code. I'll try to get it up when I'm more easily able to contribute.
Assigning to myself to do this for the unicode tables because @jyn514 indicated it might be the only one that's worth doing (no strong opinions from me, although I don't like that one being python)
Once Cargo script becomes stabilized, it should become feasible to turn some of these Python scripts into one-file Rust scripsts (of course only where it would make sense, there's no point in doing that proactively).
Of the remaining Python scripts in tests
, most are gdb visualizer scripts, so trying to remove those doesn't make sense.
The one outlier is run-make/libtest-junit/validate_junit.py
, which just takes advantage of Python's built-in XML parser to check for well-formed XML output. As noted in #129387, it's not worth pulling in a Rust XML crate just to get rid of one trivial Python script in one relatively-minor test.
(If we ever reach the point where building/testing the compiler without Python is feasible, we can just add a compiletest directive to skip that test if Python isn't present.)
Looking at the rest of the list, I mostly see:
In terms of CI scripts, I think the choice is often Python or Bash. And I do prefer we use Python over Bash for anything non-trivial.
Running the command:
fd --extension py -E src/llvm-project
gives a list of python files inrust-lang/rust
:While there will (probably) always be a need for a little bit of Python in
bootstrap
, we should aim to replace misc scripts that really should be Written In Rust. Especially relevant are files likesrc/etc/htmldocck.py
which is therustdoc
UI test harness(!); we should rewrite this in Rust.Extra points:
bootstrap
?