exception_handler while debugging in vscode

[lpasselin]

Disclaimer: my understanding of this library is limited. I did not go through all of the code.

When debugging in vscode, we generally want the execution to pause on any "unhandled exceptions".
At this time, when using pydantic_cli, the debugger does not work this way.

A solution is to set an exception_handler that simply raises the exception.

Here is a script to explain:

import sys

from pydantic import BaseModel
from pydantic_cli import run_and_exit, to_runner


class CliModel(BaseModel):
    a: int = 123


def exception_handler(ex: BaseException):
    raise ex


def main(c: CliModel):
    raise Exception('Execution should stop at this line with vscode and "unhandled exceptions"')


if __name__ == "__main__":

    # BAD: Pauses the debugger in pydantic_cli.run_and_exit. Exception has occurred: SystemExit
    run_and_exit(CliModel, main)

    # BAD: Ends the program without pausing the debugger.
    to_runner(CliModel, main)(sys.argv[1:])

    # GOOD: Works as intended. Debugger stops in main() on the unhandled exception
    to_runner(CliModel, main, exception_handler=exception_handler)(sys.argv[1:])

This is an issue that could bother many users.

In my opinion, the default exception_handler should simply re-raise the exception.
This issue could also simply be addressed in the readme.

I really think you guys are on the right track with pydantic_cli. Thanks!

edit: I realize an easy way to solve this is to make public a function that simply parses sys.argv[1:] and returns an instance of the pydantic model. I would only use this function. Something like this:

import sys

from pydantic_cli import parse_argv_to_model_instance


def main(c: CliModel, *args, **kwargs):
    # do something
    return

if __name__ == "__main__":
    c: CliModel = parse_argv_to_model_instance(CliModel, sys.argv[1:])
    main(c)

[mpkocher]

This is kinda a fundamental design choice, not really a bug.

When writing a command tool there needs to be a husk layer that catches any/all exceptions and maps them to an integer exit code and exits the program. This design allows you to map unhandled exceptions to specific exit codes, (e.g., KeyError -> 10) and also enables the program to always execute the epilogue handler.

It can be useful to use mypy and investigating the type signatures to understand what's going on here.

The usage of to_runner below shouldn't expect an exception to be raised.

exit_code: int = to_runner(CliModel, main)(sys.argv[1:])

The exception_handler has type of Callable[[BaseException], int]. It should not raise. It only maps exceptions back to exit codes.

The default exception handler will write an exception to stderr and return 1. You can enable interactive debugging by adding ipdb or pdb to your custom exception handler. This can be useful for local debugging.

def exception_handler(ex: BaseException) -> int:
    exit_code = default_exception_handler(ex)
    import ipdb; ipdb.set_trace()
    return exit_code

However, I would recommend trying to do the majority of testing via unit tests (independent of pydantic_cli) with your main function and different instances of your pydantic data model. Once this test coverage is reasonable, it can be useful to add a few smoke tests at the integration level to make sure the tool is functional. Any bugs at this level are probably at the pydantic_cli level.

I'll add a section in the docs about debugging and using ipdb and try to help clarify the high level design. As you've pointed out, the usage of to_runner isn't as clear as it could be.

Thanks for the comments.

[lpasselin]

I understand and agree with what you are saying. There are many different valid workflows to develop code.
Also I see that pydantic-cli's goal is to only be a CLI wrapper. Still, sometimes you want to use a debugger and try the whole thing.

Is there any other way to make the cli wrapping code transparent when debugging?
iirc debugging unhandled exceptions works fine when we use a library likeclick.

---

The rest of this comment is mostly unrelated to this issue. More of a general design comment. Keep in mind I'm not a pydantic_cli expert!

We both know there is a significant gap between pydantic and the command line. Personally, I am looking for a library that can bridge the gap between pydantic and argparse. My goal is to get an ArgumentParser from a pydantic.BaseModel class and then parse sys.argv into an instance of that class. That's all I need. It's probably naive to say this but I feel like after solving the pydantic to argparse problem, the rest such as managing return codes is trivial.

From what I understand, pydantic-cli can bridge the pydantic to argparse gap already. But the functions are private. In my opinion, it oversteers by only enabling a full cli wrapper handling all of my program.

Basically, although it might seem counter productive to bypass the "CLI" part of pydantic-cli, I think it could be a better design to split wrapping and parsing. It would enable some kind of parse_argv_to_model_instance function that solves the pydantic to argparse problem, while also having cli wrapping functions available.

Don't take this in a negative way, I think you have a great library that already does what you want it to do already!

[mpkocher]

I am looking for a library that can bridge the gap between pydantic and argparse.

Pydantic_cli (by design) is not a bridge between argparse and pydantic. Pydantic_cli just happens to use argparse internally. Pydantic_cli is (hopefully) thin bridge between your Options defined as a Pydantic model and your mainrunner(opts: Options) func that has hooks into the startup, shutdown and error handling of the command line tool. Pydantic_cli also supports loading config files defined as JSON.

Pydantic_cli explicitly doesn't expose, or leak the argparse instance because it would add too much surface area and users could start mucking with the argparse instance in all kinds of unexpected ways.

Here's an (incomplete) list of other libraries that might be a better fit for your project/application requirements.

https://github.com/mpkocher/pydantic-cli#other-related-tools

Here's an example of a more leaky layer that uses dataclasses.

https://github.com/lebrice/SimpleParsing

[mpkocher]

Docs have been improved.