docs.coopcloud.tech/docs/federation/resolutions/drafts/021.md

title
Resolution 021

• Topic: Budget XXX: Flag handling in Abra
• Date: ...
• Deadline: ...
• Size: Medium

Summary

Motivated by the collective release planning: #583 under "Argument Handling".

Due to a bug in the underlying library (urfave/cli) that Abra uses for command-line argument/flag handling, we have a bug in Abra which cannot be fixed without causing a breaking change. See #581 for the ongoing discussion. This proposal is the TLDR; and proposal for the fix.

Details (Budget XXX)

The problem

The current help output of abra app deploy is as follows:

abra app deploy [command options] <domain> [<version>]

However, it is possible to do both of the following:

abra app deploy --chaos example.org  # "before" style
abra app deploy example.org --chaos  # "after" style

However, abra app cmd is broken if you try to use the "after" style:

abra app cmd <domain> <function> --local -- <args>

This results in FATA[0000] <recipe> doesn't have a --local function which is a bug in the abra code. It tries to read the position of the arguments but --local is included as an argument. The bug in abra is due to a bug in urfave/cli - "after" style options appear as arguments 😱

The only way to use abra app cmd right now is using the "before" style:

abra app cmd  --local <domain> <function> -- <args>

This means that some commands allow both "after" and "before" style and some only allow "before" style. This is a source of confusion, raised issues and frustration.

Our solution

We propose to remedy this situation by upgrading urfave/cli to version 2 which enforces the "before" style. This was the solution from urfave/cli developers to fix their bug. You can then only do e.g.

abra app deploy --chaos <domain>

This is the "simplest" option in terms of development capacity and is the most cost effective option. The upgrade effort is more or less a known quantity, see #404 for more.

We have previously reverted from version 2 to version to 1 to maintain this flexibility. However, this leaves us with an unresolved bug which we want to close off.

Alternatives

If this restriction is seen as too burdensome, we see some alternatives.

If you choose to vote against this proposal, please include your preference for an alternative (below or with your own). This allows us to mount another proposal with minimal effort.

There is no guarantee we can get these right and it will incur an ongoing maintenance cost.

1. we make a special case hack in the case of the --local handling and proceed as usual
2. we upgrade to v2 and include a patch which automatically re-orders "after" style options into the "before" style transparently

Budget

Compensate @p4u1 for 4 hours work to get this done. This includes 1 hour backpay for the initial spike in #404.