Suggestion: Improve command line interface

[erikarvstedt]

The different joinmarket scripts should be made accessible as subcommands under a single binary, like in git or systemctl.

add-utxo.py -> joinmarket add-utxo
sendpayment.py -> joinmarket sendpayment
...

This makes jm easier and more intuitive to use in a shell environment where joinmarket is in PATH.

I've noticed this while working on packaging jm for nixpkgs.

Edit: This might by superseded by gist: RPC API.

[erikarvstedt]

Another issue: The output of sendpayment.py --help doesn't specifiy if argument amount has unit btc or sat. Please always specify units when there are ambiguities.

[kristapsk]

All send amounts on command line can be specified as either BTC or sats since v0.6.0 (previously it was always sats). Integers are treated as sats, decimals as BTC, optionally "btc" or "sat" suffix can be specified (I was inspired by c-lightning here), e.g. "100000", "0.001", "100000sat" or "0.001btc" will be the same. See https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/441#issue-338270825. But likely that should be documented better.

[AdamISZ]

I'd like to mention that that gist was very much just some vague ideas, a concrete attempt, or rather a start at it, is in #670

[xanoni]

The quickest and dirtiest way to do this would be to just have a bash script wrapper that calls the python scripts via a case lookup table based on the value passed via $1.

However, I think more should be done here. This would be THE opportunity to clean up / harmonize all the command line arguments between commands. See my ticket here: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/922

[AdamISZ]

@xanoni I do agree it's a very helpful plan to harmonize them. I don't currently have time to do it, personally, but would support others as much as possible.

[xanoni]

@xanoni I do agree it's a very helpful plan to harmonize them. I don't currently have time to do it, personally, but would support others as much as possible.

I know Python and I love consistency, so this is something I could do if people have a bit of patience (as always, lots of things going on). Ok?

[AdamISZ]

I know Python and I love consistency, so this is something I could do if people have a bit of patience (as always, lots of things going on). Ok?

OK with me :) Nobody has final say of course, important to remember. I doubt there will be conflict with someone else doing the same thing.

[AdamISZ]

A few more comments in case it helps:

As per Erik's original comment:

Edit: This might by superseded by gist: RPC API.

Do note that there is active work on this RPC API in someone's fork (i.e. further dev on #670 ) though it may take a while to percolate. Consider if it's best to make use of this model, or (I suspect you'll prefer this as it's less ambitious), to write a python script without an RPC to a "jmwalletd" daemon.

For completeness I think the functions are:

• All wallet-tool functions, pay attention to that (a) all of these only require read-only access to wallet, (b) some do not require a password, (c) some do not require a check of the blockchain backend ('noscan'). There is at least one actually wallet-modifying method: the freeze method for changing and persisting the spendable-ness of utxos.
• sendpayment and tumbler naturally fold together anyway based on taker running 1 or more schedules.
• Remember that sendpayment is also used for sender-side payjoin, which is a substantially different workflow of course.
• receive-payjoin script for receiver side of payjoin.
• add-utxo is a far less used feature (hardly at all) but occasionally useful for creating additional podle commitments for takers
• sendtomany is even less talked about/used but you could add it in i guess
• ob-watcher.py in /obwatch starts its own http server
• there are two yield generator scripts, though everyone uses the now-default yg-privacyenhanced.py afaict.

I suppose you could quite reasonably not include the last two. But I'm guessing you do want to include the last one to keep with the theme of harmonizing options and so on.

[AdamISZ]

It's tricky to be properly complete :) I deliberately didn't include the joinmarket-qt script though it is technically a script and so could be folded in. I also didn't mention snicker/ scripts (there are several), conceivably could be added but it's not used yet; though note, the snicker-finder script is something that many people find a bit useful, for scanning for coinjoins, so you could add that.

[xanoni]

Consider if it's best to make use of this model, or (I suspect you'll prefer this as it's less ambitious), to write a python script without an RPC to a "jmwalletd" daemon.

I'm not 100% sure I understand this sentence in its entirety. Are you saying I could either create a CLI tool that calls the (WIP) RPC interface, or alternatively just create a Python script that bundles the commands (the original plan)?

[AdamISZ]

Yes, I'm saying it'd be possible to have the CLI call the RPC (so that basically everything goes through the RPC to a daemon), similar to how it works with bitcoin-cli.

[kristapsk]

There is another benefit for a single shell wrapper, it could do cd $(dirname "$0")/.. && source jmvenv/bin/activate && cd scripts at the beginning like scripts/joinmarket-qt.sh wrapper already does. This would ensure correct virtualenv is always used and also user could just symlink to this from /usr/local/bin or whatever else location on his PATH.