Merge pull request #1188 from BRAINSia/CleanTrailingWhiteSpace

STYLE: Remove end of line trailing white space

Author: hjmjohnson

README.rst

@@ -4,13 +4,13 @@ NIPYPE: Neuroimaging in Python: Pipelines and Interfaces
 
 .. image:: https://travis-ci.org/nipy/nipype.png?branch=master
   :target: https://travis-ci.org/nipy/nipype
-  
+
 .. image:: https://circleci.com/gh/nipy/nipype/tree/master.svg?style=svg
   :target: https://circleci.com/gh/nipy/nipype/tree/master
 
 .. image:: https://coveralls.io/repos/nipy/nipype/badge.png
   :target: https://coveralls.io/r/nipy/nipype
-  
+
 .. image:: https://www.codacy.com/project/badge/182f27944c51474490b369d0a23e2f32
   :target: https://www.codacy.com/app/krzysztof-gorgolewski/nipy_nipype
 
@@ -70,7 +70,7 @@ Website
 -------
 
 Information specific to Nipype is located here::
-	    
+	
     http://nipy.org/nipype
 
 
@@ -81,10 +81,10 @@ If you have a problem or would like to ask a question about how to do something
 to `NeuroStars.org <http://neurostars.org>`_ with a *nipype* tag. `NeuroStars.org <http://neurostars.org>`_  is a platform similar to StackOverflow but dedicated to neuroinformatics. All previous Nipype questions are available here::
 
        http://neurostars.org/t/nipype/
-	   
+	
 
 To participate in the Nipype development related discussions please use the following mailing list::
-       
+
        http://mail.python.org/mailman/listinfo/neuroimaging
 
 Please add *[nipype]* to the subject line when posting on the mailing list.
@@ -96,7 +96,7 @@ Nipype structure
 Currently Nipype consists of the following files and directories:
 
   INSTALL
-    NIPYPE prerequisites, installation, development, testing, and 
+    NIPYPE prerequisites, installation, development, testing, and
     troubleshooting.
 
   README

THANKS.rst

@@ -86,15 +86,15 @@ Other contributors
   * Mike Trumpis
   * Karl Young
   * Tom Waite
-  
+
 We would also like to thank `JetBrains <http://www.jetbrains.com/>`__ for providing `Pycharm <http://www.jetbrains.com/pycharm/>`__ licenses.
- 
+
 Funding
 -------
 Satrajit Ghosh work on this project was partially funded by NIBIB R03 EB008673 (PI: Ghosh and Whitfield-Gabrieli) and by the `INCF <http://www.incf.org>`__ through a contract with TankThink Labs, LLC.
-Chris Burns was supported by NIMH grant 5R01MH081909-02 (PI: Desposito). Hans Jonson was supported by 
-`2 U54 EB005149 - 06	 Core 2b Huntington's Disease - Driving Biological Project <http://projectreporter.nih.gov/project_info_description.cfm?aid=8153616&icde=16158743&ddparam=&ddvalue=&ddsub=&cr=18&csb=PT&cs=ASC>`__, 
-`S10 RR023392	 Enterprise Storage In A Collaborative Neuroimaging Environment	 <http://projectreporter.nih.gov/project_info_description.cfm?aid=7209718&icde=16158552&ddparam=&ddvalue=&ddsub=&cr=1&csb=default&cs=ASC>`__, 
-`R01 NS040068	 Neurobiological Predictors of Huntington's Disease	 <http://projectreporter.nih.gov/project_info_description.cfm?aid=6266377&icde=16158103>`__, 
+Chris Burns was supported by NIMH grant 5R01MH081909-02 (PI: Desposito). Hans Jonson was supported by
+`2 U54 EB005149 - 06	 Core 2b Huntington's Disease - Driving Biological Project <http://projectreporter.nih.gov/project_info_description.cfm?aid=8153616&icde=16158743&ddparam=&ddvalue=&ddsub=&cr=18&csb=PT&cs=ASC>`__,
+`S10 RR023392	 Enterprise Storage In A Collaborative Neuroimaging Environment	 <http://projectreporter.nih.gov/project_info_description.cfm?aid=7209718&icde=16158552&ddparam=&ddvalue=&ddsub=&cr=1&csb=default&cs=ASC>`__,
+`R01 NS040068	 Neurobiological Predictors of Huntington's Disease	 <http://projectreporter.nih.gov/project_info_description.cfm?aid=6266377&icde=16158103>`__,
 and `UL1 TR000442	University of Iowa Clinical and Translational Science Program <http://projectreporter.nih.gov/project_info_description.cfm?aid=8467220&icde=16159156&ddparam=&ddvalue=&ddsub=&cr=1&csb=default&cs=ASC>`__.
 

doc/devel/gitwash/configure_git.rst

@@ -16,15 +16,15 @@ Here is an example ``.gitconfig`` file::
   [user]
           name = Your Name
           email = you@yourdomain.example.com
-  
+
   [alias]
           ci = commit -a
           co = checkout
           st = status -a
           stat = status -a
           br = branch
           wdiff = diff --color-words
-  
+
   [core]
           editor = vim
 
@@ -33,7 +33,7 @@ Here is an example ``.gitconfig`` file::
 
 You can edit this file directly or you can use the ``git config --global``
 command::
-  
+
   git config --global user.name "Your Name"
   git config --global user.email you@yourdomain.example.com
   git config --global alias.ci "commit -a"

doc/devel/gitwash/development_workflow.rst

@@ -22,7 +22,7 @@ Workflow summary
 This way of working really helps to keep work well organized, and in
 keeping history as clear as possible.
 
-See |emdash| for example |emdash| `linux git workflow`_. 
+See |emdash| for example |emdash| `linux git workflow`_.
 
 Making a new feature branch
 ===========================
@@ -44,7 +44,7 @@ In git >1.7 you can ensure that the link is correctly set by using the
 ``--set-upstream`` option::
 
    git push --set-upstream origin my-new-feature
-   
+
 From now on git_ will know that ``my-new-feature`` is related to the
 ``my-new-feature`` branch in the github_ repo.
 
@@ -83,7 +83,7 @@ In more detail
 
 #. Check what the actual changes are with ``git diff`` (`git diff`_).
 #. Add any new files to version control ``git add new_file_name`` (see
-   `git add`_). 
+   `git add`_).
 #. To commit all modified files into the local copy of your repo,, do
    ``git commit -am 'A commit message'``.  Note the ``-am`` options to
    ``commit``. The ``m`` flag just signals that you're going to type a
@@ -92,7 +92,7 @@ In more detail
    description in the `tangled working copy problem`_. The `git commit`_ manual
    page might also be useful.
 #. To push the changes up to your forked repo on github_, do a ``git
-   push`` (see `git push`). 
+   push`` (see `git push`).
 
 Asking for code review
 ======================
@@ -121,7 +121,7 @@ Asking for code review
 The generated comparison, is between your feature branch
 ``my-new-feature``, and the place in ``master`` from which you branched
 ``my-new-feature``.  In other words, you can keep updating ``master``
-without interfering with the output from the comparison.  More detail? 
+without interfering with the output from the comparison.  More detail?
 Note the three dots in the URL above (``master...my-new-feature``).
 
 .. admonition:: Two vs three dots
@@ -165,7 +165,7 @@ When you are ready to ask for the merge of your code:
 Merging from trunk
 ==================
 
-This updates your code from the upstream `nipype github`_  repo. 
+This updates your code from the upstream `nipype github`_  repo.
 
 Overview
 --------

doc/devel/gitwash/git_development.rst

@@ -13,4 +13,4 @@ Contents:
    set_up_fork
    configure_git
    development_workflow
-   
+

doc/devel/gitwash/git_resources.rst

@@ -9,9 +9,9 @@ Tutorials and summaries
 
 * `github help`_ has an excellent series of how-to guides.
 * `learn.github`_ has an excellent series of tutorials
-* The `pro git book`_ is a good in-depth book on git. 
+* The `pro git book`_ is a good in-depth book on git.
 * A `git cheat sheet`_ is a page giving summaries of common commands.
-* The `git user manual`_ 
+* The `git user manual`_
 * The `git tutorial`_
 * The `git community book`_
 * `git ready`_ |emdash| a nice series of tutorials

doc/devel/gitwash/set_up_fork.rst

@@ -4,7 +4,7 @@
  Set up your fork
 ==================
 
-First you follow the instructions for :ref:`forking`. 
+First you follow the instructions for :ref:`forking`.
 
 Overview
 ========

doc/devel/index.rst

@@ -15,7 +15,7 @@ conventions documented in the `NIPY Developers Guide
    :maxdepth: 2
 
    writing_custom_interfaces
-   gitwash/index   
+   gitwash/index
    architecture
    provenance
    software_using_nipype

doc/devel/interface_specs.rst

@@ -130,8 +130,8 @@ base class down to subclasses).:
   ``TraitedSpec``: Nipype's primary base class for all Specs.
   Provides initialization, some nipype-specific methods and any trait
   handlers we define. Inherits from traits.HasTraits.
-  
-	  ``BaseInterfaceInputSpec``: Defines inputs common to all 
+
+	  ``BaseInterfaceInputSpec``: Defines inputs common to all
 	  Interfaces (``ignore_exception``). If in doubt inherit from this.
 
 	      ``CommandLineInputSpec``: Defines inputs common to all
@@ -141,12 +141,12 @@ base class down to subclasses).:
 	        (``outputtype``)
 
 	        ``SPMCommandInputSpec``: Defines inputs common to all SPM classes (``matlab_cmd``, ``path``, and ``mfile``)
-	        
+	
 	        ``FSTraitedSpec``: Defines inputs common to all FreeSurfer classes
 	        (``sbjects_dir``)
-	        
+	
 	        ``MatlabInputSpec``: Defines inputs common to all Matlab classes (``script``, ``nodesktop``, ``nosplash``, ``logfile``, ``single_comp_thread``, ``mfile``, ``script_file``, and ``paths``)
-	        
+	
 	        ``SlicerCommandLineInputSpec``: Defines inputs common to all Slicer classes (``module``)
 
 Most developers will only need to code at the the interface-level (i.e. implementing custom class inheriting from one of the above classes).
@@ -199,23 +199,23 @@ Common
 	        self.error( object, name, value )
 	      File "/Users/cburns/local/lib/python2.5/site-packages/enthought/traits/trait_handlers.py", line 175, in error
 	        value )
-	    TraitError: The 'infile' trait of a BetInputSpec instance must be a file 
+	    TraitError: The 'infile' trait of a BetInputSpec instance must be a file
 	    name, but a value of 'does_not_exist.nii' <type 'str'> was specified.
-	    
+	
 ``hash_files``
 	To be used with inputs that are defining output filenames. When this flag
 	is set to false any Nipype will not try to hash any files described by this
 	input. This is useful to avoid rerunning when the specified output file
 	already exists and has changed.
-	    
+	
 ``desc``
 	All trait objects have a set of default metadata attributes.  ``desc``
 	is one of those and is used as a simple, one-line docstring.  The
 	``desc`` is printed when users use the ``help()`` methods.
 
 	**Required:** This metadata is required by all nipype interface
 	  classes.
-	  
+	
 ``usedefault``
 	Set this metadata to True when the *default value* for the trait type
 	of this attribute is an acceptable value.  All trait objects have a
@@ -257,7 +257,7 @@ Common
 	    <undefined>
 	    >>> rlgn.inputs.jobtype
 	    'estwrite'
-	    
+	
 ``xor`` and ``requires``
 	Both of these accept a list of trait names. The ``xor`` metadata reflects
 	mutually exclusive traits, while the requires metadata reflects traits
@@ -268,10 +268,10 @@ Common
 	the help function.
 
 ``copyfile``
-	This is metadata for a File or Directory trait that is relevant only in 
-	the context of wrapping an interface in a `Node` and `MapNode`. `copyfile` 
-	can be set to either `True` or `False`. `False` indicates that contents 
-	should be symlinked, while `True` indicates that the contents should be 
+	This is metadata for a File or Directory trait that is relevant only in
+	the context of wrapping an interface in a `Node` and `MapNode`. `copyfile`
+	can be set to either `True` or `False`. `False` indicates that contents
+	should be symlinked, while `True` indicates that the contents should be
 	copied over.
 
 ``min_ver`` and ``max_ver``
@@ -346,10 +346,10 @@ CommandLine
 	generated for this parameter *if-and-only-if* the user did not provide
 	one.  The nipype convention is to automatically generate output
 	filenames when not specified by the user both as a convenience for the
-	user and so the pipeline can easily gather the outputs. Requires 
+	user and so the pipeline can easily gather the outputs. Requires
 	``_gen_filename()`` method to be implemented. This way should be used if the
 	desired file name is dependent on some runtime variables (such as file name
-	of one of the inputs, or current working directory). In case when it should 
+	of one of the inputs, or current working directory). In case when it should
 	be fixed it's recommended to just use ``usedefault``.
 
 ``sep``
@@ -393,7 +393,7 @@ and methods:
 * ``output_spec``: the OutputSpec
 * ``_list_outputs()``: Returns a dictionary containing names of generated files that are expected after package completes execution.  This is used by ``BaseInterface.aggregate_outputs`` to gather all output files for the pipeline.
 
-  
+
 CommandLine
 ^^^^^^^^^^^