You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guide/contributors/architecture.md
+18-6Lines changed: 18 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ descriptions = {
23
23
"site": "Documentation site, built with `make run mkdocs build` (git-ignored).",
24
24
"src": "The source of our Python package(s). See [Sources](#sources) and [Program structure](#program-structure).",
25
25
"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/griffe/_internal": "Our internal API, hidden from users. See [Program structure](#program-structure).",
27
27
"tests": "Our test suite. See [Tests](#tests).",
28
28
".copier-answers.yml": "The answers file generated by [Copier](https://copier.readthedocs.io/en/stable/). See [Boilerplate](#boilerplate).",
29
29
"devdeps.txt": "Our development dependencies specification. See [`make setup`][command-setup] command.",
@@ -98,19 +98,31 @@ The tools used in tasks have their configuration files stored in the `config` fo
98
98
99
99
## Sources
100
100
101
-
Sources are located in the `src` folder, following the [src-layout](https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/). We use [PDM-Backend](https://backend.pdm-project.org/) to build source and wheel distributions, and configure it in `pyproject.toml` to search for packages in the `src` folder.
101
+
Sources are located in the `packages/` subfolders, following the [src-layout](https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/).
102
+
We use [Hatch](https://hatch.pypa.io/latest/) to build source and wheel distributions, and configure it in `pyproject.toml`.
102
103
103
104
## Tests
104
105
105
-
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.
106
+
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 our `pyproject.toml`files to get the full list of files included in our source distributions for every individual package within the `packages/` folder.
106
107
107
108
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.
108
109
109
110
## Program structure
110
111
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`.
112
+
Griffe is split into two pieces: the library and the CLI.
112
113
113
-
Users then import `griffe` directly, or import objects from it.
114
+
Each of them has an internal API contained within an `_internal` folder:
115
+
116
+
-`packages/griffelib/src/griffe/_internal` for the library,
117
+
-`packages/griffecli/src/griffecli/_internal` for the CLI.
118
+
119
+
Griffe can be installed in library-only mode, which means that the CLI package from `packages/griffecli` is not present.
120
+
Library-only mode can be preferred if the user does not utilize the CLI functionality of Griffe and does not want to incorporate its dependencies.
121
+
122
+
The top-level `packages/griffelib/src/griffe/__init__.py` module exposes all the public API available: it always re-exports internal objects from various submodules of `griffe._internal` and, if the CLI is installed, it re-exports the public API of `griffecli` as well.
123
+
124
+
Users then import `griffe` directly, or import objects from it. If they don't have `griffecli` installed, they cannot import the CLI-related functionality,
125
+
such as [`griffecli.check`][].
114
126
115
127
We'll be honest: our code organization is not the most elegant, but it works :shrug: Have a look at the following module dependency graph, which will basically tell you nothing except that we have a lot of inter-module dependencies. Arrows read as "imports from". The code base is generally pleasant to work with though.
116
128
@@ -122,7 +134,7 @@ if os.getenv("DEPLOY") == "true":
description = "Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API."
0 commit comments