Skip to content

Commit 1c3b869

Browse files
Copilotjohnslavik
authored andcommitted
Fix griffe._internal references to griffelib._internal in docs
Co-authored-by: johnslavik <[email protected]>
1 parent 879be4e commit 1c3b869

File tree

5 files changed

+19
-19
lines changed

5 files changed

+19
-19
lines changed

docs/extensions/official/runtime-objects.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ This extension stores runtime objects corresponding to each loaded Griffe object
1515
>>> griffe_data["parse"].extra
1616
defaultdict(<class 'dict'>, {'runtime-objects': {'object': <function parse at 0x78685c951260>}})
1717
>>> griffe_data["Module"].extra
18-
defaultdict(<class 'dict'>, {'runtime-objects': {'object': <class 'griffe._internal.models.Module'>}})
18+
defaultdict(<class 'dict'>, {'runtime-objects': {'object': <class 'griffelib._internal.models.Module'>}})
1919
```
2020

2121
It can be useful in combination with mkdocstrings-python and custom templates, to iterate over object values or their attributes that couldn't be loaded by Griffe itself (for example, objects built dynamically and loaded as attributes won't have "members" to iterate over).

docs/guide/contributors/architecture.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ descriptions = {
2323
"site": "Documentation site, built with `make run mkdocs build` (git-ignored).",
2424
"src": "The source of our Python package(s). See [Sources](#sources) and [Program structure](#program-structure).",
2525
"src/griffe": "Our public API, exposed to users. See [Program structure](#program-structure).",
26-
"src/griffe/_internal": "Our internal API, hidden from users. See [Program structure](#program-structure).",
26+
"packages/griffelib/src/griffelib/_internal": "Our internal API, hidden from users. See [Program structure](#program-structure).",
2727
"tests": "Our test suite. See [Tests](#tests).",
2828
".copier-answers.yml": "The answers file generated by [Copier](https://copier.readthedocs.io/en/stable/). See [Boilerplate](#boilerplate).",
2929
"devdeps.txt": "Our development dependencies specification. See [`make setup`][command-setup] command.",
@@ -104,11 +104,11 @@ Sources are located in the `src` folder, following the [src-layout](https://pack
104104

105105
Our test suite is located in the `tests` folder. It is located outside of the sources as to not pollute distributions (it would be very wrong to publish a `tests` package as part of our distributions, since this name is extremely common), or worse, the public API. The `tests` folder is however included in our source distributions (`.tar.gz`), alongside most of our metadata and configuration files. Check out `pyproject.toml` to get the full list of files included in our source distributions.
106106

107-
The test suite is based on [pytest](https://docs.pytest.org/en/8.2.x/). Test modules reflect our internal API structure, and except for a few test modules that test specific aspects of our API, each test module tests the logic from the corresponding module in the internal API. For example, `test_finder.py` tests code of the `griffe._internal.finder` internal module, while `test_functions` tests our ability to extract correct information from function signatures, statically. The general rule of thumb when writing new tests is to mirror the internal API. If a test touches to many aspects of the loading process, it can be added to the `test_loader` test module.
107+
The test suite is based on [pytest](https://docs.pytest.org/en/8.2.x/). Test modules reflect our internal API structure, and except for a few test modules that test specific aspects of our API, each test module tests the logic from the corresponding module in the internal API. For example, `test_finder.py` tests code of the `griffelib._internal.finder` internal module, while `test_functions` tests our ability to extract correct information from function signatures, statically. The general rule of thumb when writing new tests is to mirror the internal API. If a test touches to many aspects of the loading process, it can be added to the `test_loader` test module.
108108

109109
## Program structure
110110

111-
The internal API is contained within the `src/griffe/_internal` folder. The top-level `griffe/__init__.py` module exposes all the public API, by importing the internal objects from various submodules of `griffe._internal`.
111+
The internal API is contained within the `packages/griffelib/src/griffelib/_internal` folder. The top-level `griffe/__init__.py` module exposes all the public API, by importing the internal objects from `griffelib`, which itself imports from various submodules of `griffelib._internal`.
112112

113113
Users then import `griffe` directly, or import objects from it.
114114

@@ -122,7 +122,7 @@ if os.getenv("DEPLOY") == "true":
122122
from pydeps.target import Target
123123

124124
cli.verbose = cli._not_verbose
125-
options = cli.parse_args(["src/griffe", "--noshow", "--reverse"])
125+
options = cli.parse_args(["packages/griffelib/src/griffelib", "--noshow", "--reverse"])
126126
colors.START_COLOR = 128
127127
target = Target(options["fname"])
128128
with target.chdir_work():

docs/guide/users/loading.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -214,10 +214,10 @@ from package1 import X
214214
False
215215
>>> package2["X"].target
216216
Traceback (most recent call last):
217-
File "griffe/_internal/models.py", line 1375, in _resolve_target
217+
File "griffelib/_internal/models.py", line 1375, in _resolve_target
218218
resolved = self.modules_collection.get_member(self.target_path)
219219
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
220-
File "griffe/_internal/mixins.py", line 84, in get_member
220+
File "griffelib/_internal/mixins.py", line 84, in get_member
221221
return self.members[parts[0]].get_member(parts[1:]) # type: ignore[attr-defined]
222222
~~~~~~~~~~~~^^^^^^^^^^
223223
KeyError: 'package1'
@@ -226,13 +226,13 @@ The above exception was the direct cause of the following exception:
226226

227227
Traceback (most recent call last):
228228
File "<stdin>", line 1, in <module>
229-
File "griffe/_internal/dataclasses.py", line 1310, in target
229+
File "griffelib/_internal/dataclasses.py", line 1310, in target
230230
self.resolve_target()
231-
File "griffe/_internal/dataclasses.py", line 1369, in resolve_target
231+
File "griffelib/_internal/dataclasses.py", line 1369, in resolve_target
232232
self._resolve_target()
233-
File "griffe/_internal/dataclasses.py", line 1377, in _resolve_target
233+
File "griffelib/_internal/dataclasses.py", line 1377, in _resolve_target
234234
raise AliasResolutionError(self) from error
235-
griffe._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
235+
griffelib._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
236236
```
237237

238238
As you can see in the interpreter session above, Griffe did not resolve the `X` alias. When we tried to access its target object anyway, it failed with a `KeyError`, which was raised again as an [`AliasResolutionError`][griffe.AliasResolutionError].
@@ -250,7 +250,7 @@ False # Hmm?
250250
>>> package2["X"].target
251251
Traceback (most recent call last):
252252
...
253-
griffe._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
253+
griffelib._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
254254
```
255255

256256
The same exception again? What happened here? We loaded both packages, but Griffe still failed to resolve the alias. That is expected; here is the explanation.

docs/guide/users/navigating.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -14,17 +14,17 @@ When [loading an object](loading.md), Griffe will give you back an instance of o
1414
```python
1515
>>> import griffe
1616
>>> type(griffe.load("markdown"))
17-
<class 'griffe._internal.models.Module'>
17+
<class 'griffelib._internal.models.Module'>
1818
>>> type(griffe.load("markdown.core.Markdown"))
19-
<class 'griffe._internal.models.Class'>
19+
<class 'griffelib._internal.models.Class'>
2020
>>> type(griffe.load("markdown.Markdown"))
21-
<class 'griffe._internal.models.Alias'>
21+
<class 'griffelib._internal.models.Alias'>
2222
>>> type(griffe.load("markdown.core.markdown"))
23-
<class 'griffe._internal.models.Function'>
23+
<class 'griffelib._internal.models.Function'>
2424
>>> type(griffe.load("markdown.markdown"))
25-
<class 'griffe._internal.models.Alias'>
25+
<class 'griffelib._internal.models.Alias'>
2626
>>> type(griffe.load("markdown.Markdown.references"))
27-
<class 'griffe._internal.models.Attribute'>
27+
<class 'griffelib._internal.models.Attribute'>
2828
```
2929

3030
However deep the object is, Griffe loads the entire package. It means that in all the cases above, Griffe loaded the whole `markdown` package. The model instance Griffe gives you back is therefore part of a tree that you can navigate.

docs/reference/api/expressions.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Expressions
22

3-
::: griffe._internal.expressions
3+
::: griffelib._internal.expressions
44
options:
55
members: false
66
show_root_heading: false

0 commit comments

Comments
 (0)