Skip to content

feat(cargo-acap-*): Add --manifest-path#232

Open
apljungquist wants to merge 1 commit intomainfrom
acap-rs-manifest-path
Open

feat(cargo-acap-*): Add --manifest-path#232
apljungquist wants to merge 1 commit intomainfrom
acap-rs-manifest-path

Conversation

@apljungquist
Copy link
Copy Markdown
Collaborator

Previously this could be passed to cargo after --, but doing so typically would not work since cargo-acap-build internally invokes Cargo to get the target dir. Now we explicitly parse that option and propagate it to all cargo subcommands.

I also considered leaving it after --, infer any manifest path from those args and propagate it explicitly only for the internal cargo sub- commands. I'm honestly unsure which is better.

Pros (of the current implementation):

  • No fragile, ad-hoc parsing of arguments. There are many ways this could go wrong. We could forget to handle both "=" and " ", we could forget to handle "--" (any --manifest-path after such an argument would probably not go to cargo).
  • It's clear to educated users which arguments directly affect the behavior of the cargo-acap-* programs.

Cons:

  • The public interface of the programs change
  • Our interface requires --manifest-path to come before the command while cargo expects it after the command.

Previously this could be passed to cargo after `--`, but doing so
typically would not work since `cargo-acap-build` internally invokes
Cargo to get the target dir. Now we explicitly parse that option and
propagate it to all cargo subcommands.

I also considered leaving it after `--`, infer any manifest path from
those args and propagate it explicitly only for the internal cargo sub-
commands. I'm honestly unsure which is better.

Pros (of the current implementation):
- No fragile, ad-hoc parsing of arguments. There are many ways this
  could go wrong. We could forget to handle both "=" and " ", we could
  forget to handle "--" (any --manifest-path after such an argument
  would probably not go to cargo).
- It's clear to educated users which arguments directly affect the
  behavior of the `cargo-acap-*` programs.

Cons:
- The public interface of the programs change
- Our interface requires `--manifest-path` to come before the command
  while `cargo` expects it after the command.
@apljungquist apljungquist requested a review from a team as a code owner April 5, 2026 11:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant