feat(cli): Run command on the package closest to the current directory

[aakoshh]

Description

Problem*

Resolves #2606

Summary*

Changed the behaviour of the CLI to look for:

• the innermost manifest if neither --workspace nor --package is given, ie. find the manifest of the current directory
• the outermost manifest if either --workspace or --package is given (the latter so we can test package b when we're in the directory of package a)

Added a new PackageOptions struct to contain the above two options, to cut down some of the repetition in the commands.

Added a nargo_toml::find_root function that takes a workspace flag to indicate whether we want the outer or inner package.

I did not change the LSP which calls find_package_manifest in test requests, it will keep finding the workspace manifest:

• on_test_request_inner tests all packages, so in theory it could use the innermost package, and then if the editor was opened in a package, rather than on the whole workspace, it could limit the scope of tests; I'm not sure if we want to change this, so I left it as-is.
• on_test_run_request_inner gets the name of the crate to test in the request parameters - this will only work reliably if we allow the package to be found in the workspace.

Additional Context

Testing

Using the overlapping_dep_and_mod for testing because it has two members in its workspace: foo and bin; the latter actually has overlapping_dep_and_mod as package name.

❯ cd test_programs/compile_success_empty/overlapping_dep_and_mod/foo/src

❯ cargo run -q -p nargo_cli -- --program-dir . test
[foo] Running 0 test functions
[foo] 0 tests passed

❯ cargo run -q -p nargo_cli -- --program-dir . test --package foo
[foo] Running 0 test functions
[foo] 0 tests passed

❯ cargo run -q -p nargo_cli -- --program-dir . test --package bin
Selected package `bin` was not found

❯ cargo run -q -p nargo_cli -- --program-dir . test --package overlapping_dep_and_mod
[overlapping_dep_and_mod] Running 0 test functions
[overlapping_dep_and_mod] 0 tests passed

❯ cargo run -q -p nargo_cli -- --program-dir . test --workspace
[overlapping_dep_and_mod] Running 0 test functions
[overlapping_dep_and_mod] 0 tests passed
[foo] Running 0 test functions
[foo] 0 tests passed

❯ cd ../..

❯ cargo run -q -p nargo_cli -- --program-dir . test 
[overlapping_dep_and_mod] Running 0 test functions
[overlapping_dep_and_mod] 0 tests passed

❯ cargo run -q -p nargo_cli -- --program-dir . test --workspace
[overlapping_dep_and_mod] Running 0 test functions
[overlapping_dep_and_mod] 0 tests passed
[foo] Running 0 test functions
[foo] 0 tests passed

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Compilation Sample

Program	Compilation Time	%
sha256_regression	0m1.449s	-6%
regression_4709	0m1.532s	-1%
ram_blowup_regression	0m16.763s	-1%

[github-actions]

Peak Memory Sample

Program	Peak Memory	%
keccak256	81.38M	0%
workspace	121.85M	-1%
regression_4709	333.59M	0%
ram_blowup_regression	2.55G	0%

[michaeljklein]

Do the docs need to be updated?

I see your comment:

Using the overlapping_dep_and_mod for testing because it has two members in its workspace:
..

Please add one or more unit tests along these lines. I only see test_find_root_does_not_panic

[aakoshh]

I couldn’t see anything in the docs that mentioned the current behaviour, and both the —package and —workspace options are hidden, so I just added explanation to those for the folks who know where to look. Because the ticket says this change ought to bring it in line with how cargo works I thought this behaviour would not need explanation. Actually I think —workspace is mentioned, but that works the same way as it did before. I’ll have another look if the default scope needs to be mentioned somewhere.

Regarding unit test, okay, will add something. Didn’t do it because it relies on finding TOML files in the file system, so it requires a bit of cumbersome setup.

[aakoshh]

@michaeljklein added docs and tests, PTAL.

[github-actions]

🚀 Deployed on https://67584e7b007e3e63650cf8cc--noir-docs.netlify.app

[TomAFrench]

There's been a couple of instances of people wanting to put a nargo project within another nargo project without creating a workspace. This has been blocked by the fact that the outer nargo toml will fail to be registered as a workspace config but with this PR that will no longer happen.

Can you add some documentation saying that we don't support nested packages except within a workspace so that if we re-break this in future then it's not an issue.

[TomAFrench]

Looks good.

[TomAFrench]

@michaeljklein Can you take another look as you're currently blocking this pr.

[github-actions]

FYI @noir-lang/developerrelations on Noir doc changes.

[michaeljklein]

LGTM