Add build_package convenience function to cargo-miden

[Keinberger]

Right now, using cargo-miden as a library to compile a project and get a Package back requires a fair amount of boilerplate: calling run(), matching on CommandOutput::BuildCommandOutput, then on BuildOutput::Masm, reading the artifact bytes from disk, and finally deserializing with Package::read_from_bytes().

The compiler's own test harness already wraps this internally (build_package() in test-harness, compile_rust_package() in integration-network helpers), so the pattern is well established.

I think it would be worth exposing a simple public function on the cargo-miden crate that wraps this entire pipeline:

pub fn build_package(manifest_path: &Path, release: bool) -> Result<Package>

Happy to work on implementing this!

Context: these helpers currently live in the project template which we provide to pioneer teams as a starting point for building with the Rust compiler. The goal is to extract and standardize helpers that right now temporarily exist there, so that they're available to all developers natively.

[bitwalker]

cargo-miden is not designed for use as a library (to the extent it has a public API at all, it is for internal testing use only, and is definitely considered an internal implementation detail) - so we first should address that IMO.

Could you perhaps elaborate on why that approach was taken, rather than invoking miden build or cargo miden build via the command line? Is there missing functionality that makes that not an option? If so, I'd much rather address those deficiencies than try to make the cargo-miden extension a library.

From what I can see, using the cargo-miden crate as a library isn't actually gaining you anything, i.e. you are building up an argument vector and passing it to cargo_miden::run, so you could just as easily pass that vector to a std::process::Command. Since you ultimately need to read the package from disk anyway, there is no reason to take on the burden of depending directly on the cargo-miden crate (it requires building your tool with a specific nightly toolchain, the internal APIs being used could change at any time, and just building the compiler itself is time consuming. Being able to shed that dependency would make things a lot easier on yourself IMO.

/cc @greenhat

[greenhat]

We're discussing where to put it in 0xMiden/protocol#2611. And yes, we would rather not use cargo-miden dep for this.

[Keinberger]

Thanks for the feedback, Paul. I now understand that cargo-miden isn't designed as a library and using std::process::Command is a reasonable alternative. The current usage in the project template essentially just constructs a CLI arg vector and passes it to cargo_miden::run, so switching to a subprocess call would be straightforward.

I saw this is being discussed in protocol#2611. The current direction is to rename the existing miden-testing to miden-protocol-testing and create a new top-level miden-testing that includes the compilation helper (using std::process::Command rather than depending on cargo-miden).

Given that #2611 covers this, I think we should close this issue in favor of that discussion.