Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use yapf to autoformat the Altair specifications in docs and examples #3673

Open
mattijn opened this issue Nov 3, 2024 · 1 comment
Open

Comments

@mattijn
Copy link
Contributor

mattijn commented Nov 3, 2024

What is your suggestion?

As said by @dangotbanned in #3544 (review):

yapf

@mattijn I haven't looked into this in much detail yet, but have some thoughts.

Since it has both a CLI and module interface - there may be multiple ways we could use it with the code block stuff I added in #3630.

I called out #3570 (comment) directly there, as this was the exact use case I had in mind.
If we went down that route, I'd still prefer to keep that separate from this PR.

I do want to reiterate that I feel more strongly towards some form of autoformatting for examples - than a specific style.
My preference is ruff, but within reason, I'm happy for this to be anything that others agree upon

Everybody prefers autoformatted Altair specifications in the docs and in the examples. Let’s hope we can finish this discussion using the described approach🙏


Adapted from #3630 (comment)

class CodeRefDirective(SphinxDirective):

The addition of CodeRefDirective allows directly referencing the contents of a function in the docs.

There is also some interesting stuff in https://github.com/vega/altair/blob/main/tools/codemod.py that can be adapted to support this use case.
The short explanation is this supports rewriting & reformatting code to be used elsewhere.
So this would have the benefit of writing in the same style as the rest of altair code, but support autoformatting for a possibly different style if agreed upon in #3519.

More generally though, a move towards writing code blocks in .py vs .rst has other benefits from a maintenance perspective:

  • Code reusability
  • Code blocks updating in response to IDE refactoring
  • Clearer diffs during review
  • Full access to tools like ruff, mypy to ensure code quality

Have you considered any alternative solutions?

ruff it. ruff also provides autoformatting, but the proposed style by ruff deviates a bit from manually written specifications (See thread).

There is also a second alternative using ruff, which was mentioned in #3570 (reply in thread)

It may be helpful to compare the effect each tool/config has on a sample of the examples.

Note

Edited by @dangotbanned

@dangotbanned
Copy link
Member

Formatting User Guide

This would require some decision on the Deferred item in #3630

What I imagined there would be similar to polars/docs/source/src.
They use mkdocs, so ignore that part, but the idea of having a parallel hierarchy to the .rst files.

Below is one current usage of the directive:

.. altair-code-ref:: tests.altair_theme_test.alt_theme_test
:fold:
:summary: Show Vega-Altair Theme Test code

Which is more generally:

.. altair-code-ref:: package.module.*.function

So if we moved more code to .py files and structured the filesystem, it could look like:

.. altair-code-ref:: doc.src.user_guide.customization.alt_theme_test

Maybe worth adding an option for the doc.src.user_guide prefix?

.. altair-code-ref:: customization.alt_theme_test
    :user_guide:

I'd still prefer not to use relative imports, but this would be applicable for almost every code block

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants