refactor and add pipeline docs

docs/api/data.rst

@@ -1,7 +1,7 @@
 Data Abstractions
 =================
 
-.. module:: lenskit.data
+.. py:module:: lenskit.data
 
 The :mod:`lenskit.data` module provides the core data abstractions LensKit uses
 to represent recommender system inputs and outputs.
@@ -15,9 +15,9 @@ Data Sets
     :caption: Data Sets
 
     Dataset
-    from_interactions_df
-    load_movielens
-    load_movielens_df
+    ~lenskit.data.from_interactions_df
+    ~lenskit.data.load_movielens
+    ~lenskit.data.load_movielens_df
 
 
 Item Data
@@ -28,7 +28,7 @@ Item Data
     :nosignatures:
     :caption: Item Data
 
-    ItemList
+    ~lenskit.data.ItemList
 
 User Data
 ---------
@@ -38,7 +38,7 @@ User Data
     :nosignatures:
     :caption: User Data
 
-    UserProfile
+    ~lenskit.data.UserProfile
 
 Identifiers
 -----------
@@ -48,4 +48,4 @@ Identifiers
     :nosignatures:
     :caption: Identifiers
 
-    Vocabulary
+    ~lenskit.data.Vocabulary

docs/api/index.rst

@@ -18,6 +18,7 @@ Core Abstractions
     :hidden:
 
     data
+    pipeline
 
 Components and Models
 ~~~~~~~~~~~~~~~~~~~~~

docs/api/pipeline.rst

@@ -0,0 +1,40 @@
+Recommendation Pipelines
+========================
+
+.. py:module:: lenskit.pipeline
+
+This page documents the LensKit pipeline API, exposed in the
+:mod:`lenskit.pipeline` module
+
+Pipeline Classes
+----------------
+
+.. autosummary::
+    :toctree: .
+    :nosignatures:
+
+    Pipeline
+    Node
+
+Component Interface
+-------------------
+
+These are the interfaces and classes you need to reference when building new
+LensKit components.
+
+.. autosummary::
+    :toctree: .
+    :nosignatures:
+
+    ConfigurableComponent
+    TrainableComponent
+    AutoConfig
+
+Standard Pipelines
+------------------
+
+.. autosummary::
+    :toctree: .
+    :nosignatures:
+
+    topn_pipeline

docs/conf.py

@@ -92,7 +92,7 @@
     "ArrayLike": "numpy.typing.ArrayLike",
     "RandomSeed": "lenskit.types.RandomSeed",
 }
-autosummary_generate_overwrite = False
+# autosummary_generate_overwrite = False
 
 todo_include_todos = True
 

docs/guide/data.rst

@@ -61,7 +61,7 @@ Users and items have two identifiers:
 
 Identifiers and numbers can be mapped to each other with the user and item
 *vocabularies* (:attr:`~Dataset.users` and :attr:`~Dataset.items`, see the
-:class:`~Vocabulary` class).
+:class:`Vocabulary` class).
 
 .. _dataset:
 

docs/guide/pipeline.rst

@@ -1,20 +1,19 @@
 Recommendation Pipelines
 ========================
 
-.. module:: lenskit.pipeline
-
-.. todo::
-    None of this has been implemented yet.
+.. py:currentmodule::
 
 Since version :ref:`2024.1`, LensKit uses a flexible “pipeline” abstraction to
 wire together different components such as candidate selectors, personalized
 item scorers, and rankers to produce predictions, recommendations, or other
 recommender system outputs.  This is a significant change from the LensKit 0.x
 design of monolithic and composable components based on the Scikit-Learn API,
 allowing new recommendation designs to be composed without writing new classes
-just for the composition.  It also makes recommender definition code more explicit
-by laying out the pipeline instead of burying composition logic in the definitions
-of different composition classes.
+just for the composition.  It also makes recommender definition code more
+explicit by laying out the pipeline instead of burying composition logic in the
+definitions of different composition classes.  The pipeline lives in the
+:mod:`lenskit.pipeline` module, and the primary entry point is the
+:class:`Pipeline` class.
 
 If all you want to do is build a standard top-N recommendation pipeline from an
 item scorer, see :func:`topn_pipeline`; this is the equivalent to
@@ -77,13 +76,6 @@ abstraction Karl Higley created for POPROX_.
 .. _Haystack: https://docs.haystack.deepset.ai/docs/pipelines
 .. _POPROX: https://ccri-poprox.github.io/poprox-researcher-manual/reference/recommender/poprox_recommender.pipeline.html
 
-Common Pipelines
-~~~~~~~~~~~~~~~~
-
-These functions make it easy to create common pipeline designs.
-
-.. autofunction:: topn_pipeline
-
 .. _pipeline-model:
 
 Pipeline Model
@@ -285,21 +277,6 @@ pipeline will emit a warning (or fail, if ``allow_pickle=False`` is passed to
     The load/save parameter operations are modeled after PyTorch's
     :meth:`~torch.nn.Module.state_dict` and the needs of ``safetensors``.
 
-Pipeline Class
-~~~~~~~~~~~~~~
-
-.. autoclass:: Pipeline
-
-Pipeline Nodes
-~~~~~~~~~~~~~~
-
-Pipeline nodes are represented by :class:`Node` objects.  For the purposes of
-client code, these should be considered opaque objects usable only to reference
-a node.
-
-.. autoclass:: Node
-    :members: name
-
 Component Interface
 ~~~~~~~~~~~~~~~~~~~
 
@@ -325,11 +302,3 @@ memory parallelism in its batch-inference code.
 
     Is it clear to write these capabilities as separate protocols, or would it be
     better to write a single ``Component`` :class:`~abc.ABC`?
-
-.. autodata:: Component
-
-.. autoclass:: ConfigurableComponent
-
-.. autoclass:: TrainableComponent
-
-.. autoclass:: AutoConfig