Replace external dependencies with re-exports

[varun-doshi]

Ref #1145

Currently replaced external dependencies in the following packages:

• miden-obejcts - feat: removed external dependencies from miden-objects #1186
• miden-tx - feat: removed external dependencies from miden-lib #1188
• miden-proving-service-client - feat: remove external dependencies from proving-service-client and tx-batch-prover #1178
• miden-tx-batch-provder - feat: remove external dependencies from proving-service-client and tx-batch-prover #1178
• miden-lib - feat: removed external dependencies from miden-lib #1179

Will update this as I push changes

[PhilippGackstatter]

@varun-doshi What is the state of this PR 🙂? Would you like to continue working on this?
I think it might make sense to do one PR for one or maybe two crates at a time to avoid too many conflicts.

[varun-doshi]

@varun-doshi What is the state of this PR 🙂? Would you like to continue working on this? I think it might make sense to do one PR for one or maybe two crates at a time to avoid too many conflicts.

Apologies for the delay @PhilippGackstatter . I will get this done in the next few hours.
Also yes, good idea to split this up into multiple PRs.
I think this PR is ready to review then(will resolve the merge conflicts)

Will raise another Pr for the other 3 crates

[varun-doshi]

On second thought, if you'd like I can split this PR into 2 separate ones as well considering this PR has 40 file changes

to clarify:
miden-object: 28 file changes
miden-tx:12 file changes

Let me know how you'd like me to proceed @PhilippGackstatter

[PhilippGackstatter]

I would not import these from super. If we now remove the Word import from crates/miden-lib/src/note/mod.rs then this file would also be affected, and those should ideally be independent.
I would prefer using crate:: imports.

I think I would generally avoid super imports, as they are more likely to break during a refactor.

Could you rewrite super imports to crate or the corresponding crate, if it's not exported from the crate? For example here, AccountId should be imported from miden_objects because that's where it is originally defined and we don't re-export it from the miden-lib root, which is good.

If you're using VS Code you can set "rust-analyzer.imports.prefix": "crate" so it will prefer importing from crate::.

[PhilippGackstatter]

Let me know how you'd like me to proceed @PhilippGackstatter

Since it's all in this PR now, it's fine to keep it as one.

I think this PR does more than described in #1145. The goal is to only rewrite imports that are re-exported from the crate itself.

For example in miden-objects, we re-export assembly::Assembler:

miden-base/crates/miden-objects/src/lib.rs

Lines 35 to 40 in 6d82ff2

	pub mod assembly {
	pub use assembly::{
	mast, Assembler, AssemblyError, DefaultSourceManager, KernelLibrary, Library,
	LibraryNamespace, LibraryPath, SourceManager, Version,
	};
	}

And in this file, for example, we import Assembler from assembly directly:

miden-base/crates/miden-objects/src/account/component/mod.rs

Line 3 in 6d82ff2

use assembly::{Assembler, Compile, Library};

That is unnecessary. Here we can replace the use assembly::Assembler with a use crate::assembly::Assembler.

So the issue only applies to re-exports. Does that make sense?

Btw. your first commit is not signed. Can you sign it? Or alternatively, opening a new PR is also fine :) Thank you!

[varun-doshi]

@PhilippGackstatter I've opened a new PR for miden-objects following your suggestions about using super. Will open one for miden-lib soon.