search

saulpw / aipl

Array-Inspired Pipeline Language
MIT License
119 stars 7 forks source link

[cli] added --step, --dry-run, and carry parser in options AttrDict #17

Closed anjakefala closed 1 year ago

anjakefala commented 1 year ago

--dry-run will skip the running of @expensive operations, returning a string '<funcname(inputs)>'.

I suspect where we may run into a bug is with operations that are expected to return values of a different rank. I could not figure out how to get the rankout information from within def expensive, and I did not have a good test available to see if that case does cause a ruckus.

Parser args now get added to aipl.options which is an AttrDict. So, e.g., the check for dry_run is if aipl.options.dry_run.

--step-* are different flavours of step through debugging aids. e.g. --step-rich will print a rich table representation of what is output by each op, --step-vd will launch VisiData with the resulting tables loaded.

anjakefala commented 1 year ago

Tests are failing because the aipl fixture is not getting all of the options created by the parser.

I tried factoring out the parser settings, so we could import them into conftest.py, but that breaks pytest's flags (pytest . will work but pytest -sv . will not work). I need a bit more time to figure out a better approach. Welcome feedback.

anjakefala commented 1 year ago

Okay, that should fix it! (I checked, and running the chains/, with/without parser options still works).

The only thing is that I noticed script-or-globals is a mandatory param: https://github.com/saulpw/aipl/pull/17/files#diff-a31c7ed5d35f5ed8233994868c54d625b18e6bacb6794344c4531e62bd9dde59. I adapted in this way.

cthulahoops commented 1 year ago

Okay, that should fix it! (I checked, and running the chains/, with/without parser options still works).

The only thing is that I noticed script-or-globals is a mandatory param: https://github.com/saulpw/aipl/pull/17/files#diff-a31c7ed5d35f5ed8233994868c54d625b18e6bacb6794344c4531e62bd9dde59. I adapted in this way.

The script_or_global thing is a bit weird. It was a work around because I wanted to add argparse without breaking anything.

I'd suggest that we add a flag for globals so we do:

aipl -g a=1 --global b=2 script1.aipl script2.aipl
cthulahoops commented 1 year ago

The script_or_global thing is a bit weird. It was a work around because I wanted to add argparse without breaking anything.

I do see you're relying on your this weirdness to workaround an issue. I don't think parsing args is right here because not all args are passed to the interpreter. (eg. you need a script to run main, but not to create an interpreter instance.)