taskipy VS typer

pdbpp: Improved pdb boltons: assorted python addtions twisted: event driven networking framework sorcery: Dark magic in python, things know where+how they are being called, helps reducing boilerplate sh: Better alternative for subprocess module, much more pythonic taskipy: npm run scipt_name like functionality snoop: pdb lite, record+replay function steps birdseye: graphical debugger remote-pdb: easy pdb from inside containers typer: wrapper around click for simpler code for CLIs arrow: Always TZ aware datetimes, plus more features more-itertools: more functions for iterators pydantic: data validation + dataclasses loguru: better logging notifiers: sending notifications from python

Taskipy

taskipy – complementary task runner for python

I always use Taskipy https://github.com/illBeRoy/taskipy to run tasks in my applications, works really well with Poetry so when I am running my dev Flask/FastAPI server and Celery or running my tests or format my code it's all there.

```

In legacy (don't break anything) mode, there's still no reason to not switch. I export `requirements.txt` with poetry just for pip legacy reasons and it works great. If I just update some scripts, I could avoid it. It's running all the time in CI, it's exercised quite a bit.

What's wrong with just using pip and requirements.txt? There's no dev section. In addition, bumping deps is not the same. I have [a blog post](https://squarism.com/2021/09/10/sciencing-out-updates/) explaining semver updates to a python dev.

_my strong assertion:_ Python and Go missed it from the start. That's why it is so confusing. There's no other choice in Rust but Cargo. Rust devs are never confused on how to add a package, semver it. The answer is always Cargo. It's in the tutorial. It's in the book. It's in the culture.

I think I've heard that pip might support the pyproject spec, poetry already does. If you want scripts like npm, you can have that too with [taskipy](https://github.com/illBeRoy/taskipy). You don't have to.

taskipy

I have been using Typer on every one of my CLI projects which uses Click under the hood. The documentation is fantastic, the CLI app it produces looks great and lets you create things quickly. I high recommend it.

https://typer.tiangolo.com/

Adding CLI capabilities. My preferred library here is typer.

I just heard about this but it seems to be pretty much the type of thing you want and want fast.

Docstrings are for documenting how a function/ class/ method/ module works. Often you don't need to add a docstring to your main function because no one will be importing it to use elsewhere. And if you want it to run as a CLI, then there are better ways to document the available options. For example, typer does most of it for you, or in click you add the help text to the decorator.

Most computing tasks in airflow DAGs are KubernetesPodOperator containing a CLI (Python Typer). It allows us to pass arguments easily to run DAG manually if needed (the new UI to pass arguments to DAG in airflow 2.6 is really nice). Arguments allow us to replay DAG easily (change start / end dates for instance).

So it's basically the main .gitlab-ci.yml file plus a separate Python CI app using Typer for the AWS instrumentation.

Similarly for Typer, which is literally "the FastAPI of CLIs"[1]. Handy to type your `main` parameters and have CLI argument parsing. For more complicated cases, it's a wrapper around Click.

[1] https://typer.tiangolo.com/

interesting that you hate python, but love Click. Did you try Typer which uses Click underneath?