Kinda crazy to see #Griffe mentioned as inspiration for the design of #OpenAI's Agents SDK Cool to see the SDK's API reference being documented with #mkdoctrings, too
Kinda crazy to see #Griffe mentioned as inspiration for the design of #OpenAI's Agents SDK Cool to see the SDK's API reference being documented with #mkdoctrings, too
We're starting to have a number of #Griffe extensions They're all listed here: https://mkdocstrings.github.io/griffe/extensions/official/
I added a few pages to #Griffe's docs: alternative projects, downstream projects, and built-in/official/third-party extensions.
Very cool projects mentioned in there! #Docspec, #pdoc, #papyri, #quartodoc, etc. And I discovered a few Griffe extensions in the process, it's awesome
- https://mkdocstrings.github.io/griffe/alternatives/
- https://mkdocstrings.github.io/griffe/downstream-projects/
- https://mkdocstrings.github.io/griffe/extensions/built-in/
I think #Griffe is ready for v1. Just one more v0 release to communicate one last deprecation.
I'm marking all the deprecated stuff in #Griffe with #Yore comments.
Yore is a new tool of mine that helps you manage legacy code. You write comments above lines or blocks of code, with a simple grammar for applying transformations once a version is reached (e.g. 1.0.0) or once a minor Python version reaches its End Of Life.
I'm adding tests to #Griffe, that use Griffe to check if:
- all public objects are exposed in the top-level init module
- all public objects are added to the API docs (HTML), and therefore if they are added to the objects inventory (#Sphinx-like objects.inv file)
- if no other object is added to the inventory (no private objects)
Thanks to these tests I made sure not to forget *anything* while rewriting Griffe's docs!
I'm completely rewriting #Griffe's docs. Griffe is all about public APIs, so its API docs should be exemplary.
These will be the best docs I've written until now. I've taken inspiration from projects with great documentation: #Hatch, #MaterialforMkDocs and #Textual notably
I'm experimenting with moving all my code into a private package, and exposing every public object in the top-level init module of a sibling public package:
- _griffe has all the internal API
- griffe exposes public objects
I added a test to my tests file that loads the internal #API (using #Griffe of course ) and checks that every "public" name in the internal API is exposed in the public package. Impossible to miss some, and that forces me to privatize the rest.
Working towards a v1.0 for #Griffe. I will enjoy removing all the legacy code used for backward compatibility
We're not there yet. See the milestone: https://github.com/mkdocstrings/griffe/milestone/1
It's good to be challenged by users.
I was reluctant to add support in #Griffe for some conventions used in the #Python ecosystem to mark objects as "exported".
To make proper arguments, I had to take a good, serious look at my codebase again. By doing so, I actually identified issues and clear improvements, that once fixed/refactored would allow Griffe to easily support these conventions in a way that makes complete sense
https://github.com/mkdocstrings/python/issues/39#issuecomment-2137083119
Quite the feature in #Griffe: the ability to force using dynamic analysis to extract data from #Python packages. Previously it would use static analysis by default and only fallback to dynamic analysis for built-in/compiled modules. Now you can use dynamic analysis for modules with sources available too
This wasn't an easy change as I thought, but I'm happy how the code evolved.
I've just released v0.45.0. Crossed-fingers for no regressions (tests added, but, you know, can't ever be sure)
Thanks @orsinium. Until now I was fighting this (trying to find out the true parent module), but seeing how inconsistent this is, I give up and will just use what Python gives me.
To give more context: I'm trying to improve the code in #Griffe that inspects object trees (dynamic analysis). To know whether an object should be added to the currently inspected module as a member or as an alias pointing to somewhere else, I have to check where the object originates from.
https://github.com/mkdocstrings/griffe/commit/d1696b03a67560a997176d42d07b32395cf723d7
I have published a "best practices" document in #Griffe's docs:
https://mkdocstrings.github.io/griffe/best_practices/
It says:
- avoid member-submodule name shadowing (the issue described above )
- avoid wildcard imports
- prefer canonical imports (we recommend @15r10nk's canonical-import tool!)
These recommendations are given from a "static analysis" and "public API" point of view.
I'll gradually add more of these
#Griffe (Insiders) just got a new feature: expressions modernization.
It will allow downstream tools like #mkdocstrings to render type annotations compatible with older Python versions, as if they were using latest features of the #Python language.
Typically:
- typing.Union[int, str] becomes int | str
- typing.Optional[int] becomes int | None
- typing.Set[int] becomes set[int]
- etc.
https://mkdocstrings.github.io/griffe/expressions/#modernization
#Python devs, do you often have a submodule and a member with the same name?
For example:
- pkg/__init__.py declares `thing = 1`
- pkg also has a `thing.py` submodule
#Griffe does not support that and will ignore the member in such cases, giving priority to the submodule. This limitation has been reported multiple times, and I wanted to fix it, but after having worked on it a bit, I'm quite convinced I shouldn't, and instead should say it's bad practice.
https://github.com/mkdocstrings/griffe/issues/124#issuecomment-1981072243
Next version of #Griffe will bring improved support for dataclasses. They are actually a PITA to handle statically 200 LoC + 160 LoC for tests.