Some corrections to documentation

docs/source/backends/list.rst

@@ -17,18 +17,6 @@ or manually. More complicated in structure packages would need an additional wra
 
 Please see the provided list of :ref:`reference_templates`.
 
-TomoPy software (CPU)
----------------------
-`TomoPy <https://tomopy.readthedocs.io>`_ is an open-source Python package for
-tomographic data processing and image reconstruction developed at
-`The Advanced Photon Source <https://www.aps.anl.gov/>`_ in Illinois, USA.
-The project is active since 2013 and it gained a `large audience <https://github.com/tomopy/tomopy>`_
-of users and contributors across tomographic imaging community.
-
-* TomoPy is an open-source package in Python and C for data processing and reconstruction. TomoPy is mostly a CPU processing library and in HTTomo we expose the CPU modules only.
-* It is a CPU-multithreaded package. HTTomo controls parallelisation through MPI on a higher level and also supports local CPU multithreading from TomoPy, for every MPI process.
-* TomoPy is a library of stand-alone methods which can be easily integrated into HTTomo. Notably not all TomoPy methods are integrated in HTTomo because of the I/O nature of some modules. Please see the list of available TomoPy :ref:`reference_templates`.
-
 HTTomolibgpu library (GPU)
 --------------------------
 `HTTomolibgpu <https://github.com/DiamondLightSource/httomolibgpu>`_ library is developed at `Diamond Light source  <https://www.diamond.ac.uk/>`_
@@ -41,3 +29,15 @@ by Data Analysis Group to work together with the HTTomo software.
 HTTomolib library (CPU)
 --------------------------
 `HTTomolib <https://github.com/DiamondLightSource/httomolib>`_ library is similar to HTTomolibgpu, but contains mostly CPU modules.
+
+TomoPy software (CPU)
+---------------------
+`TomoPy <https://tomopy.readthedocs.io>`_ is an open-source Python package for
+tomographic data processing and image reconstruction developed at
+`The Advanced Photon Source <https://www.aps.anl.gov/>`_ in Illinois, USA.
+The project is active since 2013 and it gained a `large audience <https://github.com/tomopy/tomopy>`_
+of users and contributors across tomographic imaging community.
+
+* TomoPy is an open-source package in Python and C for data processing and reconstruction. TomoPy is mostly a CPU processing library and in HTTomo we expose the CPU modules only.
+* It is a CPU-multithreaded package. HTTomo controls parallelisation through MPI on a higher level and also supports local CPU multithreading from TomoPy, for every MPI process.
+* TomoPy is a library of stand-alone methods which can be easily integrated into HTTomo. Notably not all TomoPy methods are integrated in HTTomo because of the I/O nature of some modules. Please see the list of available TomoPy :ref:`reference_templates`.

docs/source/backends/templates.rst

@@ -4,13 +4,12 @@
 Methods YAML Templates
 ======================
 
-This section refers to YAML templates from :ref:`backends_list` which are distributed separately through `httomo-backends`. 
+This section refers to YAML templates from :ref:`backends_list` which are distributed separately through `httomo-backends`.
 You will be redirected to the `httomo-backends` page where those templates can be either copy-pasted or
 downloaded in order to help you to construct your pipeline.
 
-`TomoPy Modules <https://diamondlightsource.github.io/httomo-backends/backends/templates.html#tomopy-modules>`_
-
 `HTTomolibgpu Modules <https://diamondlightsource.github.io/httomo-backends/backends/templates.html#httomolibgpu-modules>`_
 
 `HTTomolib Modules <https://diamondlightsource.github.io/httomo-backends/backends/templates.html#httomolib-modules>`_
 
+`TomoPy Modules <https://diamondlightsource.github.io/httomo-backends/backends/templates.html#tomopy-modules>`_

docs/source/conf.py

@@ -23,13 +23,14 @@
 import os
 import sys
 from datetime import date
-
+from unittest import mock
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 
 sys.path.insert(0, os.path.abspath("../.."))
 
+
 # -- Mock imports -------------------------------------------------------------
 
 autodoc_mock_imports = [
@@ -39,8 +40,21 @@
     "h5py",
     "hdf5plugin",
     "httomo_backends",
+    "scipy",
+    "scipy.signal",
 ]
 
+
+
+class CustomMock(mock.Mock):
+    def __repr__(self):
+        return "<cp.ndarray>"
+
+
+sys.modules["scipy"] = CustomMock()
+sys.modules["scipy.signal"] = CustomMock()
+
+
 # ------------------------------------------------------------------------------
 
 project = "HTTomo"

docs/source/howto/installation.rst

@@ -34,7 +34,7 @@ Conda environment
 
 .. code-block:: console
 
-   $ conda env create --name httomo
+   $ conda create --name httomo
    $ conda activate httomo
    $ conda install -c conda-forge cupy==12.3.0 openmpi==4.1.6 h5py[build=*openmpi*]
    $ conda install -c conda-forge tomopy==1.15 # optional

docs/source/howto/process_lists/save_results/save_results.rst

@@ -3,20 +3,18 @@
 Saving intermediate files
 +++++++++++++++++++++++++
 
-As explained in :ref:`httomo-saving`, by default, HTTomo will *not* write the
-output of a method to a file unless under certain conditions (please see the
-link for a description of these file-saving conditions).
+HTTomo, by default, will *not* write the output of a method to a file unless under certain conditions (please see more in :ref:`httomo-saving`).
 
 HTTomo can be informed to write or not write the output of a method to a file
 with the :code:`save_result` parameter. Its value is a boolean, so either
-:code:`True` or :code:`False` are valid values for it.
+:code:`true` or :code:`false` are valid values for it.
 
 
 Example 1: save output of a specific method
 ###########################################
 
 Suppose we wanted to save the output of the normalisation function :code:`normalize`. Then we
-should add :code:`save_result: True` to the list of the function parameters, but NOT the method's parameters:
+should add :code:`save_result: true` to the list of the function parameters, but NOT the method's parameters:
 
 .. code-block:: yaml
   :emphasize-lines: 8
@@ -28,7 +26,7 @@ should add :code:`save_result: True` to the list of the function parameters, but
       minus_log: true
       nonnegativity: false
       remove_nans: false
-    save_result: True
+    save_result: true
 
 Example 2: using :code:`--save_all` and :code:`save_result` together
 ####################################################################
@@ -51,4 +49,4 @@ would like to save the output of all methods using :code:`--save_all`, *apart* f
       minus_log: true
       nonnegativity: false
       remove_nans: false
-    save_result: False
+    save_result: false

docs/source/howto/run_httomo.rst

@@ -273,7 +273,8 @@ the output of a method to a file in the output directory unless one of the
 following conditions is satisfied:
 
 - the method is the last one in the processing pipeline
-- the :code:`save_result` parameter has been provided a value of :code:`True` in
+- the method is a reconstruction method
+- the :code:`save_result` parameter has been provided a value of :code:`true` in
   a method's YAML configuration (see :ref:`save-result-examples` for more info
   on the :code:`save_result` parameter)
 

docs/source/reference/loaders.rst

@@ -133,7 +133,7 @@ in the older scan should be ignored. In this instance, we need to provide a para
 :code:`file` and :code:`data_path` fields.
 
 .. code-block:: yaml
-   :emphasize-lines:7,11
+   :emphasize-lines: 7,11
 
 
     - method: standard_tomo
@@ -163,7 +163,7 @@ This is the case when darks or flats still present in the dataset, but one needs
 the keyword :code:`ignore` into the loader, like in the example below where both flats and darks are ignored:
 
 .. code-block:: yaml
-   :emphasize-lines:7,8
+   :emphasize-lines: 4-5
 
 
     - method: standard_tomo

httomo/cli.py

@@ -22,7 +22,15 @@
 from httomo.runner.task_runner import TaskRunner
 from httomo.ui_layer import UiLayer, PipelineFormat
 
-from . import __version__
+
+try:
+    from . import __version__
+except:
+    __version__ = "0.0.1" # temporary version for sphinx build
+    pass
+
+
+
 
 
 class PipelineFilePathOrString(click.ParamType):