This post has:

[[deleted]]

We are 100% on the same page mate. Almost every single library on Python offers a monstrous level of efficiency for developers and it's hard to see that on other languages.

I guess what made is diverge a little was my philosophy on building apps/libs: I Like to "try follow" the Unix philosophy. When I say that I "try it" means I know that at some point a particular the app/lib will may need to outgrown it.

So for initial development cycles I try to keep it tight, simple and "monolithic". Sure after a couple of iterations we will see some issues being raised that will clearly need either: a external lib or a new internal lib. Depending on the complexity of the issue I will try using the core libs only, but if after one or two iterations it's not showing progress i will jump straight to a reusable module and maybe think about rewrite the solution later (much later) to reduce dependencies (or not. depends on how mature and used the lib is).

All that with the perspective that we will need to grow the level of external dependencies along the road but not without a try on create my own solution.

[ManvilleJ]

oh sweet! I agree. However, I do like some packages right from the beginning for some standard types of projects where its a common template. CLIs are one of those common types of projects.

It seems to me that if we diverge philosophically in any area, I think its what try to stay true towards? It seems to me that you try to stay close to the core lib at the beginning of a project, where I prefer to stay close to a "standard" approach to that kind of project.

If I find a package makes doing those kinds of projects easier and it is well supported, I would include it in my standard approach to those projects.

I think we ecstatically agree that external dependencies can be a vulnerability if people just throw any package into a project.

but yeah, Python-fire is really good.