workingjubilee
commented
2 years ago Hm. UI design is not trivially obvious here.
Major consideration: It may seem like this is a "validation" step and so it wants to be part of the "validator function", but is that the best idea? That predetermines the validator function call point: before the build is actually run. And the validator also is always called with no arguments, which makes it annoying to configure what the validator actually does in terms of checks aside from already-supplied methods. We want to have this as an option for catching a nefarious build.rs that might be executed, and we want to have an unambiguous path to doing so.
While #27 is no longer on the table, in order to make #70 happen, and to make #26 easy, PL/Rust needs builds that are slightly more finely staged and offer more user input, so the user can easily recover things like the Cargo.toml and Cargo.lock that PL/Rust is going to use. In addition, we would like to run the build under various debug or other settings of their choice. Currently, we hardcode all build settings to run once the crate is provisioned:
https://github.com/tcdi/plrust/blob/37c2c493e0b057ff33dc0784e3b28b66fff8d0a4/src/user_crate/state_provisioned.rs#L49-L61
For correctness purposes, it is important that after crate generation and before the build that PL/Rust guarantees that "nothing happens" from the perspective of actually running the build. However, this is also probably the perfect time for events which examine the crate without actually fully building and running it.
We want to be careful about exposing control over the build options that are input, as compiler options are implicitly "unsafe". Thus, unlimited access to the compiler's command flags may allow instructing the compiler to run the build under parameters that can hypothetically violate any safety properties we have embedded in the PL/Rust design.