Skip to content

Enable Sphinx configuration caching #570

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

Open
tc85324 opened this issue Apr 24, 2024 · 1 comment · May be fixed by #1012
Open

Enable Sphinx configuration caching #570

tc85324 opened this issue Apr 24, 2024 · 1 comment · May be fixed by #1012
Labels
enhancement New feature or request

Comments

@tc85324
Copy link
Contributor

tc85324 commented Apr 24, 2024

What's the new feature?

Properly handle #561 to permit caching.

What value does this add?

Allows proper caching.

Is there an alternative you've considered?

No response

Additional context

No response

@tc85324 tc85324 added enhancement New feature or request new Something yet to be discussed by development team labels Apr 24, 2024
@tp832944 tp832944 removed the new Something yet to be discussed by development team label Jul 10, 2024
@bk958178
Copy link
Contributor

bk958178 commented Sep 2, 2024

Blocked by #664, pending next major Sphinx release

tm91236 added a commit that referenced this issue Mar 31, 2025
By removing the `typehints_formatter` we are able to resolve
issues #570 and #734. The former issue is resolved by removing
the non-picklable function, which enables build caching, and the
second is solved by removing the `TypeVar` bound replacement.

While the `TypeVar` replacement does provide more concise
documentation, it removes a key piece of information, which the
reader must be aware of. For example, in:
```python
T = TypeVar("T", bound=Data)

def typevar(a: T, b: T) -> None: ...
def bound(a: Data, b: Data): ...

def valid(a: SupervisedData, b: SupervisedData): ...
def invalid(a: Data, b: SupervisedData): ...
```
the `typevar` function is the actual specification, `bound` is the
documented specification, `valid` is a valid specification, and
`invalid` is an invalid specification which is presented as valid
in the documentation (if we replace the `TypeVar` with the bound).

As an additional comment, we do now lose the functionality of the
`autodoc_custom_types` -- it should be noted that the `ArrayLike`
custom type (the only listed custom type) doesn't appear to be
used anywhere in the codebase.
tm91236 added a commit that referenced this issue Mar 31, 2025
By removing the `typehints_formatter` we are able to resolve
issues #570 and #734. The former issue is resolved by removing
the non-picklable function, which enables build caching, and the
second is solved by removing the `TypeVar` bound replacement.

While the `TypeVar` replacement does provide more concise
documentation, it removes a key piece of information, which the
reader must be aware of. For example, in:
```python
T = TypeVar("T", bound=Data)

def typevar(a: T, b: T) -> None: ...
def bound(a: Data, b: Data): ...

def valid(a: SupervisedData, b: SupervisedData): ...
def invalid(a: Data, b: SupervisedData): ...
```
the `typevar` function is the actual specification, `bound` is the
documented specification, `valid` is a valid specification, and
`invalid` is an invalid specification which is presented as valid
in the documentation (if we replace the `TypeVar` with the bound).

As an additional comment, we do now lose the functionality of the
`autodoc_custom_types` -- it should be noted that the `ArrayLike`
custom type (the only listed custom type) doesn't appear to be
used anywhere in the codebase.

Refs: #570, #734
@tm91236 tm91236 linked a pull request Mar 31, 2025 that will close this issue
9 tasks
tm91236 added a commit that referenced this issue Mar 31, 2025
By removing the `typehints_formatter` we are able to resolve
issues #570 and #734. The former issue is resolved by removing
the non-picklable function, which enables build caching, and the
second is solved by removing the `TypeVar` bound replacement.

While the `TypeVar` replacement does provide more concise
documentation, it removes a key piece of information, which the
reader must be aware of. For example, in:
```python
T = TypeVar("T", bound=Data)

def typevar(a: T, b: T) -> None: ...
def bound(a: Data, b: Data): ...

def valid(a: SupervisedData, b: SupervisedData): ...
def invalid(a: Data, b: SupervisedData): ...
```
the `typevar` function is the actual specification, `bound` is the
documented specification, `valid` is a valid specification, and
`invalid` is an invalid specification which is presented as valid
in the documentation (if we replace the `TypeVar` with the bound).

As an additional comment, we do now lose the functionality of the
`autodoc_custom_types` -- it should be noted that the `ArrayLike`
custom type (the only listed custom type) doesn't appear to be
used anywhere in the codebase.

Refs: #570, #734
@tm91236 tm91236 linked a pull request Mar 31, 2025 that will close this issue
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants