feature: could you make `colorama` an optional dependenncy

[samuelcolvin]

Is your feature request related to a problem? Please describe.

AFAIK colorama is only used in the griffe CLI. We're using griffe programatically in pydantic-ai-slim where we care a lot about minimizing the SBOM.

Describe the solution you'd like

Would you consider removing the colorama dependency, or making it optional in a cli dependency group. 🙏

[pawamoy]

Yes good idea, I like reducing dependencies too 🙂

[pawamoy]

I see two options:

1. Move library code into a new package called griffelib. Have griffe depend on it (as well as colorama, like before). Re-expose the API from griffe. Library users like Pydantic-AI can start depending on griffelib instead of griffe to get minimal dependencies. No breaking changes.
2. Start putting colorama under an extra. Small breaking change for users who use colored output.

I myself prefer option 1. Never got to write this blog post but that's how I want to architect my CLI/lib projects from now on:

• <pkg>lib stores the library only, with minimal dependencies
• <pkg> is the CLI, it depends on <pkg>lib and maybe re-exposes its whole API
• (optional) <pkg>-tui (or <pkg>tui without dash) provides a TUI (with Textual of course)

The reason I like this architecture is that users don't have to learn/know about extras. It makes commands shorter (uvx pkg command instead of uvx --from pkg[cli] pkg command, or uvx pkgtui instead of uvx --from pkg[tui] pkg tui). I find it intuitive that installing the main pkg package gets you both the library + CLI. In such cases as above, it also makes a smooth transition without breaking changes (so, takes into account the evolution of a project).

[samuelcolvin]

yup, option 1 makes sense.

It's roughly the same idea as how we have pydantic-ai-slim with all the application logic (includes the pydantic_ai module), but only minimal dependencies, then pydantic-ai is a dependency only library that includes pydantic-ai-slim and lots of dependencies.

[johnslavik]

I'm also +1 on the first option.

[johnslavik]

I filed #408 to track the migration. Any migration-related discussion is welcome there.

[pawamoy]

Closing since @johnslavik made the split 🙏 🚀 ! This will part of the next release, which will be a major bump (removal of unrelated deprecated API).

• Installing the griffe distribution will still get you the API and CLI, therefore with colorama.
• (The griffe distribution is now a meta-distribution that provides no code and depends on griffelib and griffecli)
• If you want the slim version (no colorama), you can depend on griffelib instead. Your imports can stay unchanged: the griffelib distribution provides the griffe package, so importing (from) griffe will still work as usual.
• The versions of these distributions will always be in sync: griffe==x.y.z will always depend on griffelib==x.y.z and griffecli==x.y.z. They'll be released in tandem every time (thanks uv workspaces, hatchling and uv-dynamic-versioning!)

[pawamoy]

OK v2 is live 🙂