junifer 0.0.4.dev691__tar.gz → 0.0.4.dev733__tar.gz

{junifer-0.0.4.dev691 → junifer-0.0.4.dev733}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: junifer
-Version: 0.0.4.dev691
+Version: 0.0.4.dev733
 Summary: JUelich NeuroImaging FEature extractoR
 Author-email: Fede Raimondo <f.raimondo@fz-juelich.de>, Synchon Mandal <s.mandal@fz-juelich.de>
 Maintainer-email: Fede Raimondo <f.raimondo@fz-juelich.de>, Synchon Mandal <s.mandal@fz-juelich.de>

{junifer-0.0.4.dev691 → junifer-0.0.4.dev733}/docs/builtin.rst

@@ -25,7 +25,7 @@ Data Grabber
     - In Progress
     - Done
 
-    Version added: If the status is "Done", the Junifer version in which the
+    Version added: If the status is "Done", the junifer version in which the
     dataset was added. Else, a link to the Github issue or pull request
     implementing the dataset. Links to github can be added by using the
     following syntax: :gh:`<issue number>`
@@ -122,6 +122,54 @@ Planned
      - :gh:`47`
 
 
+Preprocessor
+------------
+
+..
+    Provide a list of the Preprocessors that are implemented or planned.
+
+    State: this should indicate the state of the preprocessor. Valid options are
+    - Planned
+    - In Progress
+    - Done
+
+    Version added: If the status is "Done", the junifer version in which the
+    preprocessor was added. Else, a link to the Github issue or pull request
+    implementing the preprocessor. Links to github can be added by using the
+    following syntax: :gh:`<issue number>`
+
+Available
+~~~~~~~~~
+
+.. list-table::
+   :widths: auto
+   :header-rows: 1
+
+   * - Class
+     - Description
+     - State
+     - Version Added
+   * - :class:`.fMRIPrepConfoundRemover`
+     - Remove confounds from ``fMRIPrep``-ed data
+     - Done
+     - 0.0.1
+   * - :class:`.SpaceWarper`
+     - | Warp / transform data from one space to another
+       | (subject-native or other template spaces)
+     - Done
+     - 0.0.4
+   * - ``Smoothing``
+     - | Apply smoothing to data, particularly useful when dealing with
+       | ``fMRIPrep``-ed data
+     - In Progress
+     - :gh:`161`
+
+
+..
+   Planned
+   ~~~~~~~
+
+
 Marker
 ------
 
@@ -133,7 +181,7 @@ Marker
     - In Progress
     - Done
 
-    Version added: If the status is "Done", the Junifer version in which the
+    Version added: If the status is "Done", the junifer version in which the
     marker was added. Else, a link to the Github issue or pull request
     implementing the marker. Links to github can be added by using the
     following syntax: :gh:`<issue number>`
@@ -254,10 +302,6 @@ Planned
    * - Connectedness
      - Compute connectedness
      - :gh:`34`
-   * - Permutation entropy, Range entropy, Multiscale entropy and Hurst exponent
-     - | Calculate Permutation entropy, Range entropy, Multiscale entropy and
-       | Hurst exponent
-     - :gh:`61`
 
 Parcellation
 ------------
@@ -265,7 +309,7 @@ Parcellation
 ..
     Provide a list of the Parcellations that are implemented or planned.
 
-    Version added: The Junifer version in which the parcellation was added.
+    Version added: The junifer version in which the parcellation was added.
 
 Available
 ~~~~~~~~~
@@ -277,8 +321,8 @@ Available
    * - Name
      - Options
      - Keys
-     - Spaces
-     - Version added
+     - Template Spaces
+     - Version Added
      - Publication
    * - Schaefer
      - ``n_rois``, ``yeo_networks``
@@ -439,7 +483,7 @@ Coordinates
 ..
     Provide a list of the Coordinates that are implemented or planned.
 
-    Version added: The Junifer version in which the parcellation was added.
+    Version added: The junifer version in which the parcellation was added.
 
 Available
 ~~~~~~~~~
@@ -450,7 +494,7 @@ Available
 
    * - Name
      - Keys
-     - Version added
+     - Version Added
      - Publication
    * - Cognitive action control
      - ``CogAC``
@@ -635,7 +679,7 @@ Mask
 ..
     Provide a list of the masks that are implemented or planned.
 
-    Version added: The Junifer version in which the mask was added.
+    Version added: The junifer version in which the mask was added.
 
 Available
 ~~~~~~~~~
@@ -646,8 +690,8 @@ Available
 
    * - Name
      - Keys
-     - Spaces
-     - Version added
+     - Template Space
+     - Version Added
      - Description - Publication
    * - Vickery-Patil (Gray Matter)
      - | ``GM_prob0.2``
@@ -663,14 +707,14 @@ Available
      - | Vickery, Sam, & Patil, Kaustubh. (2022).
        | Chimpanzee and Human Gray Matter Masks [Data set]. Zenodo.
        | https://doi.org/10.5281/zenodo.6463123
-   * - Nilearn's MNI152 1mm-resolution mask
+   * - ``junifer``'s custom brain mask
      - | ``compute_brain_mask``
      - Adapts to the target data
      - 0.0.2
-     - | Compute the whole-brain mask. This mask is calculated using
-       | MNI152 1mm-resolution template mask onto the target image.
-       | See :func:`nilearn.masking.compute_brain_mask`
-   * - Nilearn's mask computed from FMRI data
+     - | Compute the whole-brain, gray-matter or white-matter mask using
+       | the template and the resolution from the target image. The
+       | templates are obtained via ``templateflow``.
+   * - ``nilearn``'s mask computed from fMRI data
      - | ``compute_epi_mask``
      - Adapts to the target data
      - 0.0.2
@@ -678,15 +722,14 @@ Available
        | proposed by T.Nichols: find the least dense point of the histogram,
        | between fractions ``lower_cutoff`` and ``upper_cutoff`` of the total
        | image histogram. See :func:`nilearn.masking.compute_epi_mask`
-   * - Nilearn's background mask
+   * - ``nilearn``'s background mask
      - | ``compute_background_mask``
      - Adapts to the target data
      - 0.0.2
      - | Compute a brain mask for the images by guessing the value of the
        | background from the border of the image.
        | See :func:`nilearn.masking.compute_background_mask`
-
-   * - Nilearn's ICBM152 template gray-matter mask
+   * - ``nilearn``'s ICBM152 template gray-matter mask
      - | ``fetch_icbm152_brain_gm_mask``
      - ``MNI152NLin2009aAsym``
      - 0.0.2
@@ -695,8 +738,9 @@ Available
        | See :func:`nilearn.datasets.fetch_icbm152_brain_gm_mask`
 
 
-Planned
-~~~~~~~
+..
+   Planned
+   ~~~~~~~
 
 ..
   helpful site for creating tables: https://rest-sphinx-memo.readthedocs.io/en/latest/ReST.html#tables

junifer-0.0.4.dev733/docs/changes/newsfragments/306.enh

@@ -0,0 +1 @@
+Add support for local ``junifer queue`` via GNU Parallel by `Synchon Mandal`_

junifer-0.0.4.dev733/docs/changes/newsfragments/314.bugfix

@@ -0,0 +1 @@
+Fix element access for :class:`.DMCC13Benchmark` DataGrabber by `Synchon Mandal`_

junifer-0.0.4.dev733/docs/changes/newsfragments/317.doc

@@ -0,0 +1 @@
+Improve documentation by adding information about space transformation and writing custom Preprocessors by `Synchon Mandal`_

{junifer-0.0.4.dev691 → junifer-0.0.4.dev733}/docs/contribution.rst

@@ -164,6 +164,8 @@ In case you remove some files or change their filenames, you can run into
 errors when using ``make local``. In this situation you can use ``make clean``
 to clean up the already build files and then re-run ``make local``.
 
+Also, we follow British English for the documentation.
+
 
 Writing Examples
 ----------------

{junifer-0.0.4.dev691 → junifer-0.0.4.dev733}/docs/extending/coordinates.rst

@@ -6,19 +6,20 @@ Adding Coordinates
 ==================
 
 Instead of using whole-brain parcellations to aggregate voxel-wise signals from
-MR images (as for example in the :class:`.ParcelAggregation` marker), junifer
+MR images (as for example in the :class:`.ParcelAggregation` marker), ``junifer``
 allows you to specify a set of coordinates around which to draw spheres to
 aggregate (for example using the :class:`.SphereAggregation` marker) the MR
 signals from individual voxels. Now, before you start specifying your own sets
-of coordinates, check the coordinates that junifer already has
+of coordinates, check the coordinates that ``junifer`` already has
 :ref:`built in <builtin>`. If you simply want to use a well known set of
-coordinates from the literature, there is a reasonable chance, that junifer
+coordinates from the literature, there is a reasonable chance, that ``junifer``
 provides them already.
 
 If you checked the in-built coordinates, and they are not there already (for
-example if you came up with your own set of coordinates), then junifer provides
-an easy way for you to register them using the :func:`.register_coordinates`
-function, so you can use your own set of coordinates within a junifer pipeline.
+example if you came up with your own set of coordinates), then ``junifer``
+provides an easy way for you to register them using the
+:func:`.register_coordinates` function, so you can use your own set of
+coordinates within a ``junifer`` pipeline.
 
 From the API reference, we can see that it has 4 positional arguments
 (``name``, ``coordinates``, ``voi_names`` and ``space``) as well as one
@@ -26,7 +27,7 @@ optional keyword argument (``overwrite``).
 
 The ``name`` argument takes a string indicating the name you want to give to
 this set of coordinates. This ``name`` can be used to obtain and operate on a
-set of coordinates in junifer. For example, you can obtain your coordinates
+set of coordinates in ``junifer``. For example, you can obtain your coordinates
 after registration by providing ``name`` to :func:`.load_coordinates`. We could
 simply call it ``"my_set_of_coordinates"``, but likely you want a more
 descriptive and more informative name most of the time.
@@ -36,9 +37,7 @@ The ``coordinates`` argument takes the actual coordinates as a 2-dimensional
 columns (one for each spatial dimension). That is, the first, second, and third
 columns indicate the x-, y-, and z-coordinates in MNI space respectively.
 The number of rows in the array correspond to the number of coordinates that
-belong to this set. Note, that junifer (as of yet) only works in MNI space, and
-so therefore these coordinates should always be real-world coordinates of the
-MNI space.
+belong to this set.
 
 The ``voi_names`` argument takes a list of strings
 indicating the names of each coordinate (i.e. volume-of-interest) in the
@@ -47,7 +46,7 @@ the number of rows in the coordinates array. Now, we know everything we need to
 know to register a set of coordinates.
 
 Lastly, we specify the ``space`` that the coordinates are in, for example,
-``"MNI"`` or ``"Native"`` (scanner-native space).
+``"MNI"`` or ``"native"`` (scanner-native space).
 
 Step 1: Prepare code to register a set of coordinates
 -----------------------------------------------------
@@ -62,8 +61,8 @@ packages:
   import numpy as np
 
 For the sake of this example, we can create a set of coordinates that belong
-to the default mode network (DMN), and register this set of coordinates with
-junifer. Note, that junifer already has a
+to the Default Mode Network (DMN), and register this set of coordinates with
+``junifer``. Note, that ``junifer`` already has a
 :ref:`set of coordinates built-in <builtin>` ("DMNBuckner") that is associated
 with the DMN. Here, we use the DMN coordinates used in a
 `nilearn example <https://nilearn.github.io/dev/auto_examples/03_connectivity/plot_sphere_based_connectome.html>`_.
@@ -97,7 +96,7 @@ simply use this to register our coordinates:
       space="MNI"
   )
 
-Now, when we run this script, junifer registers these coordinates and we can
+Now, when we run this script, ``junifer`` registers these coordinates and we can
 use them in subsequent analyses. Let's now consider how to use coordinate
 registration in combination with
 :ref:`codeless configuration using a YAML file <codeless>`.
@@ -106,7 +105,7 @@ Step 2: Add coordinate registration to the YAML file
 ----------------------------------------------------
 
 In order to register your coordinates for a pipeline configured by a YAML file,
-you can use the ``with`` keyword provided by junifer:
+you can use the ``with`` keyword provided by ``junifer``:
 
 .. code-block:: yaml
 

{junifer-0.0.4.dev691 → junifer-0.0.4.dev733}/docs/extending/datagrabber.rst

@@ -12,8 +12,8 @@ the structure of a dataset and provide two specific functionalities:
    element (e.g. the path to the T1 image, the path to the T2 image, etc.)
 #. Provide the list of *elements* available in the dataset.
 
-In this section, we will see how to create a datagrabber for a dataset. Basic
-aspects of datagrabbers are covered in the
+In this section, we will see how to create a DataGrabber for a dataset. Basic
+aspects of DataGrabbers are covered in the
 :ref:`Understanding Data Grabbers <datagrabber>` section.
 
 .. _extending_datagrabbers_think:
@@ -22,7 +22,7 @@ Step 1: Think about the element
 -------------------------------
 
 Like with any programming-related task, the first step is to think. When
-creating a Data Grabber, we need to first define what an *element* is.
+creating a DataGrabber, we need to first define what an *element* is.
 The *element* should be the smallest unit of data that can be processed. That
 is, for each element, there should be a set of data that can be processed, but
 only one of each *data type* (see :ref:`data_types`).
@@ -42,28 +42,28 @@ then the *element* should be composed of 3 items:
 If any of these items were not part of the element, then we will have more than
 one ``T1w`` and / or ``BOLD`` image for each subject, which is not allowed.
 
-Importantly, nothing prevents that one image is part of two different elements.
-For example, it is usually the case that the ``T1w`` image is not acquired for
-each task, but once in the entire session. So in this case, the ``T1w`` image
-for the element (``sub001``, ``ses1``, ``rest``) will be the same as the
-``T1w`` image for the element (``sub001``, ``ses1``, ``stroop``).
+Importantly, nothing prevents that one image being part of two different
+elements. For example, it is usually the case that the ``T1w`` image is not
+acquired for each task, but once in the entire session. So in this case, the
+``T1w`` image for the element (``sub001``, ``ses1``, ``rest``) will be the same
+as the ``T1w`` image for the element (``sub001``, ``ses1``, ``stroop``).
 
 We will now continue this section using as an example, a dataset in BIDS format
 in which 9 subjects (``sub-01`` to ``sub-09``) were scanned each during 3
 sessions (``ses-01``, ``ses-02``, ``ses-03``) and each session included a
 ``T1w`` and a ``BOLD`` image (resting-state), except for ``ses-03`` which was
-only anatomical.
+only anatomical data.
 
 Step 2: Think about the dataset's structure
 -------------------------------------------
 
 Now that we have our element defined, we need to think about the structure of
 the dataset. Mainly, because the structure of the dataset will determine how
-the Data Grabber needs to be implemented.
+the DataGrabber needs to be implemented.
 
-Junifer provides an abstract class to deal with datasets that can be thought in
-terms of *patterns*. A *pattern* is a string that contains placeholders that are
-replaced by the actual values of the element. In our BIDS example, the path
+``junifer`` provides an abstract class to deal with datasets that can be thought
+in terms of *patterns*. A *pattern* is a string that contains placeholders that
+are replaced by the actual values of the element. In our BIDS example, the path
 to the T1w image of subject ``sub-01`` and session ``ses-01``, relative to the
 dataset location, is ``sub-01/ses-01/anat/sub-01_ses-01_T1w.nii.gz``. By
 replacing ``sub-01`` with ``sub-02``, we can obtain the T1w image of the first
@@ -88,7 +88,7 @@ discussion in the `junifer Discussions`_ page. Most probably we can help you
 get your dataset in order.
 
 If there is no other way, then you can follow :ref:`extending_datagrabbers_base`
-to create a Data Grabber from scratch.
+to create a DataGrabber from scratch.
 
 .. _extending_datagrabbers_pattern:
 
@@ -101,7 +101,7 @@ Option A: Extending from PatternDataGrabber
 The :class:`.PatternDataGrabber` class is an abstract class that has the
 functionality of understanding patterns embedded in it.
 
-Before creating the datagrabber, we need to define 3 variables:
+Before creating the DataGrabber, we need to define 3 variables:
 
 * ``types``: A list with the available :ref:`data_types` in our dataset.
 * ``patterns``: A dictionary that specifies the pattern for each data type.
@@ -126,7 +126,7 @@ where the dataset is located. For example, if the dataset is located in
 location of the dataset, we can expose the variable in the constructor, as in
 the following example.
 
-With the variables defined above, we can create our datagrabber and name it
+With the variables defined above, we can create our DataGrabber and name it
 ``ExampleBIDSDataGrabber``:
 
 .. code-block:: python
@@ -152,7 +152,7 @@ With the variables defined above, we can create our datagrabber and name it
                replacements=replacements,
             )
 
-Our datagrabber is ready to be used by junifer. However, it is still unknown
+Our DataGrabber is ready to be used by ``junifer``. However, it is still unknown
 to the library. We need to register it in the library. To do so, we need to
 use the :func:`.register_datagrabber` decorator.
 
@@ -183,9 +183,9 @@ use the :func:`.register_datagrabber` decorator.
             )
 
 
-Now, we can use our datagrabber in junifer, by setting the ``datagrabber`` kind
-in the yaml file to ``ExampleBIDSDataGrabber``. Remember that we still need to
-set the ``datadir``.
+Now, we can use our DataGrabber in ``junifer``, by setting the ``datagrabber``
+kind in the yaml file to ``ExampleBIDSDataGrabber``. Remember that we still need
+to set the ``datadir``.
 
 .. code-block:: yaml
 
@@ -209,7 +209,7 @@ temporary directory. To set the location of the dataset, you can use the
 be used to specify the path to the root directory of the dataset after doing
 ``datalad clone``.
 
-In the example, the dataset is hosted in gin
+In the example, the dataset is hosted in Gin
 (``https://gin.g-node.org/juaml/datalad-example-bids``).
 
 When we clone this dataset, we will see the following structure:
@@ -238,7 +238,7 @@ Now we have our 2 additional variables:
     uri = "https://gin.g-node.org/juaml/datalad-example-bids"
     rootdir = "example_bids_ses"
 
-And we can create our datagrabber:
+And we can create our DataGrabber:
 
 .. code-block:: python
 
@@ -267,17 +267,34 @@ And we can create our datagrabber:
                replacements=replacements,
             )
 
+This approach can be used directly from the YAML, like so:
+
+.. code-block:: yaml
+
+   datagrabber:
+     - kind: PatternDataladDataGrabber
+       types:
+         - BOLD
+         - T1w
+       patterns:
+         BOLD: "{subject}/{session}/func/{subject}_{session}_task-rest_bold.nii.gz"
+         T1w: "{subject}/{session}/anat/{subject}_{session}_T1w.nii.gz"
+       replacements:
+         - subject
+         - session
+       uri: "https://gin.g-node.org/juaml/datalad-example-bids"
+       rootdir: "example_bids_ses"
 
 .. _extending_datagrabbers_base:
 
 Option B: Extending from BaseDataGrabber
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-While we could not think of a use case in which the pattern-based datagrabber
-would not be suitable, it is still possible to create a datagrabber extending
+While we could not think of a use case in which the pattern-based DataGrabber
+would not be suitable, it is still possible to create a DataGrabber extending
 from the :class:`.BaseDataGrabber` class.
 
-In order to create a datagrabber extending from :class:`.BaseDataGrabber`, we
+In order to create a DataGrabber extending from :class:`.BaseDataGrabber`, we
 need to implement the following methods:
 
 - ``get_item``: to get a single item from the dataset.
@@ -287,7 +304,7 @@ need to implement the following methods:
 .. note::
 
    The ``__init__`` method could also be implemented, but it is not mandatory.
-   This is required if the datagrabber requires any extra parameter.
+   This is required if the DataGrabber requires any extra parameter.
 
 We will now implement our BIDS example with this method.
 
@@ -339,7 +356,7 @@ method, in the same order.
       return ["subject", "session"]
 
 
-So, to summarize, our datagrabber will look like this:
+So, to summarise, our DataGrabber will look like this:
 
 .. code-block:: python
 
@@ -403,7 +420,7 @@ not standardised.
    The ``mappings`` key is only required if the ``format`` is ``adhoc``. If the
    ``format`` is ``fmriprep``, the ``mappings`` key is not required.
 
-Currently, junifer provides only one confound remover step
+Currently, ``junifer`` provides only one confound remover step
 (:class:`.fMRIPrepConfoundRemover`), which relies entirely on the ``fmriprep``
 confound variable names. Thus, if the confounds are not in ``fmriprep`` format,
 the user will need to provide the mappings between the *ad-hoc* variable names

junifer-0.0.4.dev733/docs/extending/dependencies.rst

@@ -0,0 +1,141 @@
+.. include:: ../links.inc
+
+.. _specifying_dependencies:
+
+Specifying Dependencies
+=======================
+
+This section describes how you can tackle different situations when writing
+your custom Marker and / or Preprocessor and take care of the dependencies for
+them.
+
+You might have already come across listing out dependencies for your
+:ref:`custom Markers <extending_markers>` and / or
+:ref:`custom Preprocessors <extending_preprocessors>`, if not, check them out
+first. If you have already gone through them, you are already familiar with using
+class attribute ``_DEPENDENCIES`` to keep track of its dependencies. ``junifer``
+is a bit more sophisticated about them and we will see here how you can make the
+best use of them.
+
+.. _component_dependencies:
+
+Handling dependencies that come as Python packages
+--------------------------------------------------
+
+You have already seen this case handled by having a class attribute
+``_DEPENDENCIES`` whose value is a set of all the package names that the
+component depends on. For example, for :class:`.RSSETSMarker`, we have:
+
+.. code-block:: python
+
+    _DEPENDENCIES: ClassVar[Set[str]] = {"nilearn"}
+
+The type annotation is for documentation and static type checking purposes.
+Although not required, we highly recommend you use them, your future self
+and others who use it will thank you.
+
+.. _component_external_dependencies:
+
+Handling external dependencies from toolboxes
+---------------------------------------------
+
+You can also specify dependencies of external toolboxes like AFIN, FSL and ANTs,
+by having a class attribute like so:
+
+.. code-block:: python
+
+    _EXT_DEPENDENCIES: ClassVar[List[Dict[str, Union[str, List[str]]]]] = [
+        {
+            "name": "afni",
+            "commands": ["3dReHo", "3dAFNItoNIFTI"],
+        },
+    ]
+
+The above example is taken from the class which computes regional homogeneity
+(ReHo) using AFNI. The general pattern is that you need to have the value of
+``_EXT_DEPENDENCIES`` as a list of dictionary with two keys:
+
+* ``name`` (str) : lowercased name of the toolbox
+* ``commands`` (list of str) : actual names of the commands you need to use
+
+This is simple but powerful as we will see in the following sub-sections.
+
+.. _component_conditional_dependencies:
+
+Handling conditional dependencies
+---------------------------------
+
+You might encounter situations where your Marker or Preprocessor needs to have
+option for the user to either use a dependency that comes as a package or
+use a dependency that relies on external toolboxes. With the foundation we laid
+above, it is really simple to solve it while having validation before running
+and letting the user know if some dependency is missing.
+
+Let's look at an actual implementation, in this case :class:`.SpaceWarper`, so
+that it shows the problem a bit better and how we solve it:
+
+.. code-block:: python
+
+    class SpaceWarper(BasePreprocessor):
+        # docstring
+        _CONDITIONAL_DEPENDENCIES: ClassVar[List[Dict[str, Union[str, Type]]]] = [
+            {
+                "using": "fsl",
+                "depends_on": FSLWarper,
+            },
+            {
+                "using": "ants",
+                "depends_on": ANTsWarper,
+            },
+        ]
+
+        def __init__(
+            self, using: str, reference: str, on: Union[List[str], str]
+        ) -> None:
+            # validation and setting up
+
+
+Here, you see a new class attribute ``_CONDITIONAL_DEPENDENCIES`` which is a
+list of dictionaries with two keys:
+
+* ``using`` (str) : lowercased name of the toolbox
+* ``depends_on`` (object) : a class which implements the particular tool's use
+
+It is mandatory to have the ``using`` positional argument in the constructor in
+this case as the validation starts with this and moves further. It is also
+mandatory to only allow the value of ``using`` argument to be one of them
+specified in the ``using`` key of ``_CONDITIONAL_DEPENDENCIES`` entries.
+
+For brevity, we only show the ``FSLWarper`` here but ``ANTsWarper`` looks very
+similar. ``FSLWarper`` looks like this (only the relevant part is shown here):
+
+.. code-block:: python
+
+    class FSLWarper:
+        # docstring
+
+        _EXT_DEPENDENCIES: ClassVar[List[Dict[str, Union[str, List[str]]]]] = [
+            {
+                "name": "fsl",
+                "commands": ["flirt", "applywarp"],
+            },
+        ]
+
+        _DEPENDENCIES: ClassVar[Set[str]] = {"numpy", "nibabel"}
+
+        def preprocess(
+            self,
+            input: Dict[str, Any],
+            extra_input: Dict[str, Any],
+        ) -> Dict[str, Any]:
+            # implementation
+
+Here you can see the familiar ``_DEPENDENCIES`` and ``_EXT_DEPENDENCIES`` class
+attributes. The validation process starts by looking up the ``using`` value of
+the ``_CONDITIONAL_DEPENDENCIES`` entries and then retrieves the object pointed
+by ``depends_on``. After that, the ``_DEPENDENCIES`` and ``_EXT_DEPENDENCIES``
+class attributes are checked.
+
+This might be a bit too much to get it right away so feel free to check the code
+for a better understanding. You can also check ``ALFFBase`` for a Marker
+having this pattern.

junifer-0.0.4.dev733/docs/extending/extension.rst

@@ -0,0 +1,35 @@
+.. include:: ../links.inc
+
+.. _extending_extension:
+
+Creating a ``junifer`` extension
+================================
+
+``junifer`` is designed to be easily extensible. Through the use of a registry
+and decorators, you can easily add new functionality to ``junifer`` during
+runtime. This is done by creating a new Python module and importing it before
+running ``junifer``.
+
+A special consideration has to be made when using the
+:ref:`code-less configuration<codeless>`. In this case, the
+``with`` statement can be used to import a module or run a Python file.
+
+In the following example, we instruct ``junifer`` to first import ``my_module``
+and then run the ``my_file.py`` file:
+
+.. code-block:: yaml
+
+    with:
+      - my_module
+      - my_file.py
+
+Thus, the code from ``my_file.py`` will be executed before running ``junifer``.
+This is the ideal place to include ``junifer`` extensions.
+
+.. important::
+
+   Some ``junifer`` commands will not consider files imported from files included
+   in the ``with`` statement. If ``my_file.py`` imports ``my_other_file.py``,
+   some of the ``junifer`` commands will not consider ``my_other_file.py``. Either
+   place all the code in one file or add multiple files to the ``with``
+   statement.