STY: Added some pre-commit hooks

Author: ZviBaratz

.git-blame-ignore-revs

@@ -11,4 +11,6 @@ bf298113da99079c9c7b5e1690e41879828cd472
 # Thu Dec 29 21:32:00 2022 -0500 - [email protected] - STY: isort
 0ab2856cac4d4baae7ab3e2f6d58421db55d807f
 # Thu Dec 29 21:30:29 2022 -0500 - [email protected] - STY: blue
-1a8dd302ff85b1136c81d492509b80e7748339f0
+1a8dd302ff85b1136c81d492509b80e7748339f0
+# Thu Dec 29 20:08:19 2022 +0200 - [email protected] - STY: Added some pre-commit hooks
+b42c9cad3dd247c930ae12b6de834c7424a3e658

.pre-commit-config.yaml

@@ -1,4 +1,16 @@
 repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.1.0
+    hooks:
+    -   id: trailing-whitespace
+    -   id: end-of-file-fixer
+    -   id: check-yaml
+    -   id: check-json
+    -   id: check-toml
+    -   id: check-added-large-files
+    -   id: check-case-conflict
+    -   id: check-merge-conflict
+    -   id: check-vcs-permalinks
   - repo: https://github.com/grantjenks/blue
     rev: v0.9.1
     hooks:

Makefile

@@ -38,7 +38,7 @@ RELEASE_VERSION ?= $(SETUPPY_VERSION)
 
 all: build
 
-build: 
+build:
 	$(PYTHON) setup.py config --noisy
 	$(PYTHON) setup.py build
 

Makefile.win

@@ -1,6 +1,6 @@
 # Makefile NiBabel under Windows using a standard Python distribution
 
-installer: 
+installer:
 	# now the installer
 	python setup.py bdist_wininst
 

doc/source/README.txt

@@ -16,7 +16,7 @@ Discover available make targets::
   make help
 
 Clean up previous build::
-  
+
   make clean
 
 Build html documentation::

doc/source/_templates/indexsidebar.html

@@ -19,4 +19,3 @@ <h3>Search mailing list archive</h3>
 <input name="userquery" size="18" type="text" /> <input type="submit" value="Go" />
 <input name="q" type="hidden" />
 </form>
-

doc/source/devel/biaps/biap_0001.rst

@@ -297,4 +297,3 @@ How about the names in the proposal?  ``is_proxy``; ``unproxy=True``?
 
 
 .. vim: ft=rst
-

doc/source/devel/biaps/biap_0003.rst

@@ -41,7 +41,7 @@ From `adding nifti extensions`_:
 * 4 = NIFTI_ECODE_AFNI = AFNI header attributes: The format of the AFNI
   extension in the NIfTI-1.1 format is described at
   http://nifti.nimh.nih.gov/nifti-1/AFNIextension1/
-* 6 = NIFTI_ECODE_COMMENT = comment: arbitrary non-NUL ASCII text, with no  
+* 6 = NIFTI_ECODE_COMMENT = comment: arbitrary non-NUL ASCII text, with no
   additional structure implied
 * 8 = NIFTI_ECODE_XCEDE = XCEDE metadata:
   http://www.nbirn.net/Resources/Users/Applications/xcede/index.htm
@@ -369,7 +369,7 @@ apply to the Cartesian product of the image axis values.  For example, if the
 values of ``applies_to`` == ``['slice', 'time']``, and the slice and time axes
 in the array are lengths (6, 10) respectively, then the values apply to all
 combinations of the 6 possible values for slice indices and the 10 possible
-values for the time indices (ie apply to all 6x10=60 values).  The axis metadata 
+values for the time indices (ie apply to all 6x10=60 values).  The axis metadata
 values in this case can be:
 
 * a scalar. The value applies to every combination of (slice, time)

doc/source/devel/biaps/biap_0004.rst

@@ -16,9 +16,9 @@ nibabel objects and functions.
 Motivation
 **********
 
-It is very common to convert source DICOM images to another format, typically 
-Nifti, before doing any image processing. The Nifti format is significantly 
-easier to work with and has wide spread compatibility. However, the vast 
+It is very common to convert source DICOM images to another format, typically
+Nifti, before doing any image processing. The Nifti format is significantly
+easier to work with and has wide spread compatibility. However, the vast
 amount of meta data stored in the source DICOM files will be lost.
 
 After implementing this proposal, users will be able to preserve all of the
@@ -32,7 +32,7 @@ private elements. The meta data will then be easily accessible through the
     (256, 256, 24, 8)
     >>> print nii.get_meta('RepetitionTime')
     3500.0
-    >>> echo_times = [nii.get_meta('EchoTime', (0, 0, 0, idx)) 
+    >>> echo_times = [nii.get_meta('EchoTime', (0, 0, 0, idx))
                       for idx in xrange(data.shape[-1])]
     >>> print echo_times
     [16.4, 32.8, 49.2, 65.6, 82.0, 98.4, 114.8, 131.2]
@@ -50,25 +50,25 @@ Overview
 ********
 
 dcmstack reads a series of DICOM images, works out their relationship in terms
-of slices and volumes, and compiles them into multidimensional volumes. It can 
-produce the corresponding data volume and affine, or a Nifti image (with any 
+of slices and volumes, and compiles them into multidimensional volumes. It can
+produce the corresponding data volume and affine, or a Nifti image (with any
 additional header information set appropriately).
 
-In the course of the read, dcmstack creates a `DcmMeta` object for 
-each input file. This object is an ordered mapping that can contain a copy 
-of all the meta data in the DICOM header. By default some filtering is 
-applied to reduce the chance of including PHI. The set of DcmMeta objects are 
-then merged together in the same order as the image data to create a single 
+In the course of the read, dcmstack creates a `DcmMeta` object for
+each input file. This object is an ordered mapping that can contain a copy
+of all the meta data in the DICOM header. By default some filtering is
+applied to reduce the chance of including PHI. The set of DcmMeta objects are
+then merged together in the same order as the image data to create a single
 DcmMeta object that summarizes all of the meta data for the series.
 
-To summarize the meta data, each element is classified based on how the values 
-repeat (e.g. const, per_slice, per_volume, etc.). Each element has a name (the 
-keyword from the DICOM standard) and one or more values (the number of values 
-depends on the classification and the shape of the image). Each classification's 
+To summarize the meta data, each element is classified based on how the values
+repeat (e.g. const, per_slice, per_volume, etc.). Each element has a name (the
+keyword from the DICOM standard) and one or more values (the number of values
+depends on the classification and the shape of the image). Each classification's
 meta data is stored stored in a separate nested dictionary.
 
-While creating the Nifti image output, the `DcmMeta` is stored in a 
-`DcmMetaExtension` which can be added as a header extension. This extension 
+While creating the Nifti image output, the `DcmMeta` is stored in a
+`DcmMetaExtension` which can be added as a header extension. This extension
 simply does a JSON encoding directly on the `DcmMeta` object.
 
 When working with these images, it's possible to keep track of the
@@ -78,7 +78,7 @@ slice, and remove information for other slices. Or when merging 3D volumes to
 a 4D time series, we want to merge together the meta data too.
 
 At the moment, dcmstack only creates Nifti images.  There's no reason that this
-should be so, and the relationship of dcmstack to other spatial images should be 
+should be so, and the relationship of dcmstack to other spatial images should be
 more flexible.
 
 ******
@@ -105,10 +105,10 @@ wrapping the `DcmMeta` in the Extension API?
 Status
 ------
 
-Resolved. We now have a separate `DcmMeta` object which inherits from 
-`OrderedDict` and contains all of the functionality previously in 
-`DcmMetaExtension` except those related to acting as a Nifti1Extension. 
-The `DcmMetaExtension` now provides just the functionality for being 
+Resolved. We now have a separate `DcmMeta` object which inherits from
+`OrderedDict` and contains all of the functionality previously in
+`DcmMetaExtension` except those related to acting as a Nifti1Extension.
+The `DcmMetaExtension` now provides just the functionality for being
 a Nifti1Extension.
 
 Keeping track of metadata when manipulating images
@@ -117,13 +117,13 @@ Keeping track of metadata when manipulating images
 When slicing images, it is good to be able to keep track of the relevant DICOM
 metadata for the particular slice.  Or when merging images, it is good to be
 able to compile the metadata across slices into the (e.g) volume metadata. Or,
-say, when coregistering an image, it is good to be able to know that the 
-metadata that is per-slice no longer directly corresponds to a slice of the 
-data array. 
+say, when coregistering an image, it is good to be able to know that the
+metadata that is per-slice no longer directly corresponds to a slice of the
+data array.
 
 At the moment, dcmstack deals with this by wrapping the image with DICOM meta
 information in `NiftiWrapper` object : see
-https://github.com/moloney/dcmstack/blob/master/src/dcmstack/dcmmeta.py#L1185 .
+https://github.com/moloney/dcmstack/blob/d1577412860fecd93365e0e0e097f6f87e14aee0/src/dcmstack/dcmmeta.py#L1232.
 This object accepts a Nifti image as input, that usually contains a
 `DcmMetaExtension`, and has methods `get_meta` (to get metadata from extension),
 `split` (for taking slice specific metadata into the split parts), `meta_valid`
@@ -146,8 +146,8 @@ Put the `DcmMeta` data into the `extra` object that is input to the
 Add a `get_meta` method to `SpatialImage` that uses the to-be-defined API of the
 `extra` object.  Maybe, by default, this would just get keys out of the mapping.
 
-Define an API for the `extra` object to give back metadata that is potentially 
-varying (per slice or volume). We also need a way to populate the `extra` object 
+Define an API for the `extra` object to give back metadata that is potentially
+varying (per slice or volume). We also need a way to populate the `extra` object
 when loading an image that has an associated `DcmMeta` object.
 
 Use this API to get metadata.  Try and make this work with functions outside the
@@ -179,57 +179,57 @@ Add `create_dcmmeta` method to the nibabel DICOM wrapper objects, that can be
 specialized for each known DICOM format variation.  Put the rules for slice
 information etc into each class.
 
-For the Siemens files, we will need to make a list of elements from the private 
-CSA headers that are known to be slice specific. For the multiframe DICOM files 
-we should be able to do this in a programmatic manner, since the varying data 
-should live in the PerFrameFunctionalSequence DICOM element. Each element that 
-is reclassified should be simplified with the `DcmMeta.simplify` method so that 
-it can be classified appropriately. 
+For the Siemens files, we will need to make a list of elements from the private
+CSA headers that are known to be slice specific. For the multiframe DICOM files
+we should be able to do this in a programmatic manner, since the varying data
+should live in the PerFrameFunctionalSequence DICOM element. Each element that
+is reclassified should be simplified with the `DcmMeta.simplify` method so that
+it can be classified appropriately.
 
 Meta data in nested DICOM sequences can not be independently classified
 =======================================================================
 
-The code for summarizing meta data only works on the top level of key/value 
-pairs. Any value that is a nested dataset is treated as a single entity, 
-which prevents us from classifying its individual elements differently. 
+The code for summarizing meta data only works on the top level of key/value
+pairs. Any value that is a nested dataset is treated as a single entity,
+which prevents us from classifying its individual elements differently.
 
-In a DICOM data set, any element that is a sequence contains one or more 
-nested DICOM data sets. For most MRI images this is not an issue since 
-they rarely contain many sequences, and the ones they do are usually small 
-and relatively unimportant. However in multiframe DICOM files make heavy 
+In a DICOM data set, any element that is a sequence contains one or more
+nested DICOM data sets. For most MRI images this is not an issue since
+they rarely contain many sequences, and the ones they do are usually small
+and relatively unimportant. However in multiframe DICOM files make heavy
 use of nested sequences to store data.
 
 Plan
 ----
-This same issue was solved for the translated Siemens CSA sub headers by 
-unpacking each nested dataset by joining the keys from each level with a 
-dotted notation. For example, in the `CsaSeries` subheader there is a nested 
-`MrPhoenixProtocol` dataset which has an element `ulVersion` so the key we 
-use after unpacking is `CsaSeries.MrPhoenixProtocol.ulVersion`. 
+This same issue was solved for the translated Siemens CSA sub headers by
+unpacking each nested dataset by joining the keys from each level with a
+dotted notation. For example, in the `CsaSeries` subheader there is a nested
+`MrPhoenixProtocol` dataset which has an element `ulVersion` so the key we
+use after unpacking is `CsaSeries.MrPhoenixProtocol.ulVersion`.
 
-We can take the same approach for DICOM sequence elements. One additional 
+We can take the same approach for DICOM sequence elements. One additional
 consideration is that each of these element is actually a list of data sets,
 so we would need to add an index number to the key somehow.
 
-The alternative is to handle nested data sets recursively in the meta data 
-summarizing code. This would be fairly complex and you would no longer be 
-able to refer to each element with a single string, at least not without 
+The alternative is to handle nested data sets recursively in the meta data
+summarizing code. This would be fairly complex and you would no longer be
+able to refer to each element with a single string, at least not without
 some mini-language for traversing the nested datasets.
 
 Improving access to varying meta data through the Nifti
 =======================================================
 
-Currently, when accessing varying meta data through the `get_meta` method 
+Currently, when accessing varying meta data through the `get_meta` method
 you can only get one value at a time::
 
-    >>> echo_times = [nii.get_meta('EchoTime', (0, 0, 0, idx)) 
+    >>> echo_times = [nii.get_meta('EchoTime', (0, 0, 0, idx))
                       for idx in xrange(data.shape[-1])]
 
-You can easily get multiple values from the `DcmMeta` object itself, but 
-then you lose the capability to automatically check if the meta data is 
+You can easily get multiple values from the `DcmMeta` object itself, but
+then you lose the capability to automatically check if the meta data is
 valid in relation to the current image.
 
 
 .. _dcmstack : https://github.com/moloney/dcmstack
-.. _DcmMetaExtension : https://github.com/moloney/dcmstack/blob/master/src/dcmstack/dcmmeta.py#L92
+.. _DcmMetaExtension : https://github.com/moloney/dcmstack/blob/d1577412860fecd93365e0e0e097f6f87e14aee0/src/dcmstack/dcmmeta.py#L112
 .. vim: ft=rst

doc/source/devel/biaps/biap_0006.rst

@@ -194,7 +194,7 @@ In NIfTI:
 We saw above that the MGH format refers to a volume (in our sense) as a
 *frame*.  ECAT has the same usage - a frame is a 3D volume. The fmristat
 software uses frame in the same sense, e.g., `line 32 of example.m
-<https://github.com/matthew-brett/fmristat/blob/master/fmristat/example.m#L32>`_.
+<https://github.com/matthew-brett/fmristat/blob/64ad8bf35eeb7142395659a1ff6bdcf3e69c202f/fmristat/example.m#L32>`_.
 
 Unfortunately DICOM appears to use "frame" to mean a 2D slice.  For example,
 here is the definition of a "multi-frame image"::