fix: resolved conflicts

Author: satra

.travis.yml

@@ -6,7 +6,8 @@ before_install:
     - sudo apt-get update -qq
     - sudo apt-get install lsb-release
     - source /etc/lsb-release
-    - wget -O- http://neuro.debian.net/lists/${DISTRIB_CODENAME}.us-nh | sudo tee /etc/apt/sources.list.d/neurodebian.sources.list
+    - echo ${DISTRIB_CODENAME}
+    - wget -O- http://neuro.debian.net/lists/${DISTRIB_CODENAME}.us-nh.full | sudo tee /etc/apt/sources.list.d/neurodebian.sources.list
     - sudo apt-key adv --recv-keys --keyserver pgp.mit.edu 2649A5A9
     - sudo apt-get update -qq
     - sudo apt-get install -qq python-scipy python-nose
@@ -18,4 +19,4 @@ before_install:
     - virtualenv --system-site-packages ~/virtualenv/this
     - source ~/virtualenv/this/bin/activate
 install: python setup.py build_ext --inplace
-script: make test
+script: make test

CHANGES

@@ -1,12 +1,28 @@
 Next release
 ============
 
+* ENH: New interfaces: nipy.Trim, fsl.GLM, fsl.SigLoss, spm.VBMSegment
+* ENH: Allow control over terminal output for commandline interfaces
+* ENH: New workflows for dMRI and fMRI pre-processing: added motion artifact correction
+       with rotation of the B-matrix, and susceptibility correction for EPI imaging using
+       fieldmaps. Updated eddy_correct pipeline to support both dMRI and fMRI, and new parameters.
+* ENH: Minor improvements to FSL's FUGUE and FLIRT interfaces
+* ENH: Added optional dilation of parcels in cmtk.Parcellate 
+* ENH: Interpolation mode added to afni.Resample
+
+* FIX: SpecifyModel works with 3D files correctly now.
+
+Release 0.7.0 (Dec 18, 2012)
+============================
+
 * ENH: Add basic support for LSF plugin.
-* ENH: New interfaces: ICC, Meshfix, ants.Register, C3dAffineTool, ants.JacobianDeterminant
+* ENH: New interfaces: ICC, Meshfix, ants.Register, C3dAffineTool, ants.JacobianDeterminant,
+       afni.AutoTcorrelate, DcmStack
 * ENH: New workflows: ants template building (both using 'ANTS' and the new 'antsRegistration')
 * ENH: New examples: how to use ANTS template building workflows (smri_ants_build_tmeplate), 
 	  how to set SGE specific options (smri_ants_build_template_new)
 * ENH: added no_flatten option to Merge
+* ENH: added versioning option and checking to traits
 * ENH: added deprecation metadata to traits
 * ENH: Slicer interfaces were updated to version 4.1
 

LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) 2006-2009, NIPY Developers
+Copyright (c) 2009-2013, NIPY Developers
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without

README.rst

@@ -89,16 +89,13 @@ Currently NIPYPE consists of the following files and directories:
 License information
 -------------------
 
-See the file "LICENSE" for information on the history of this
-software, terms & conditions for usage, and a DISCLAIMER OF ALL
-WARRANTIES.
+We use the 3-clause BSD license; the full license is in the file ``LICENSE`` in
+the nipype distribution.
 
-This NIPYPE distribution contains no GNU General Public Licensed
-(GPLed) code so it may be used in proprietary projects.  There
-are interfaces to some GNU code but these are entirely optional.
+There are interfaces to some GNU code but these are entirely optional.
 
 All trademarks referenced herein are property of their respective
 holders.
 
-Copyright (c) 2009-2012, NIPY Developers
+Copyright (c) 2009-2013, NIPY Developers
 All rights reserved.

doc/_templates/sidebar_versions.html

@@ -17,7 +17,7 @@ <h3>{{ _('Versions') }}</h3>
                 <td align="left">Release</td><td align="right">Devel</td>
             </tr>
             <tr>
-                <td align="left">0.6.0</td><td align="right">pre-0.7</td>
+                <td align="left">0.7.0</td><td align="right">pre-0.8</td>
             </tr>
             <tr>
                 <td align="left"><a href="{{pathto('users/install')}}">Download</a></td>

doc/devel/interface_specs.rst

@@ -263,7 +263,15 @@ Common
 	should be symlinked, while `True` indicates that the contents should be 
 	copied over.
 
-``deprecated``
+``min_ver`` and ``max_ver``
+    These metadata determine if a particular trait will be available when a
+    given version of the underlying interface runs. Note that this check is
+    performed at runtime.::
+
+	    class RealignInputSpec(BaseInterfaceInputSpec):
+	        jobtype = traits.Enum('estwrite', 'estimate', 'write', min_ver='5',
+	                              usedefault=True)
+``deprecated`` and ``new_name``
     This is metadata for removing or renaming an input field from a spec.::
 
         class RealignInputSpec(BaseInterfaceInputSpec):
@@ -277,8 +285,8 @@ Common
     from current release. Raises `TraitError` after package version crosses the
     deprecation version.
 
-``new_name``
-    For inputs that are being renamed, one can specify the new name of the field.::
+    For inputs that are being renamed, one can specify the new name of the
+    field.::
 
         class RealignInputSpec(BaseInterfaceInputSpec):
             jobtype = traits.Enum('estwrite', 'estimate', 'write',
@@ -293,6 +301,11 @@ Common
     When `new_name` is provided it must exist as a trait, otherwise an exception
     will be raised.
 
+.. note::
+
+   The version information for `min_ver`, `max_ver` and `deprecated` has to be
+   provided as a string. For example, `min_ver='0.1'`.
+
 CommandLine
 ^^^^^^^^^^^
 

doc/documentation.rst

@@ -9,7 +9,7 @@ Documentation
    :Release: |version|
    :Date: |today|
 
-Previous versions: `0.5.3 <http://nipy.org/nipype/0.5.3>`_ `0.4.1 <http://nipy.org/nipype/0.4.1>`_
+Previous versions: `0.6 <http://nipy.org/nipype/0.6>`_ `0.5.3 <http://nipy.org/nipype/0.5.3>`_ 
 
 .. container:: doc2
 

doc/users/config_file.rst

@@ -109,6 +109,11 @@ Execution
 	data through (without copying) (possible values: ``true`` and
 	``false``; default value: ``false``)
 
+*stop_on_unknown_version*
+    If this is set to True, an underlying interface will raise an error, when no
+    version information is available. Please notify developers or submit a
+    patch.
+
 Example
 ~~~~~~~
 

doc/users/install.rst

@@ -9,8 +9,8 @@ This page covers the necessary steps to install Nipype.
 Download
 --------
 
-Release 0.6.0: [`zip <http://github.com/nipy/nipype/zipball/0.6.0>`_ `tar
-<http://github.com/nipy/nipype/tarball/0.6.0>`_]
+Release 0.7.0: [`zip <https://github.com/nipy/nipype/archive/0.7.zip>`_ `tar.gz
+<https://github.com/nipy/nipype/archive/0.7.tar.gz>`_]
 
 Development: [`zip <http://github.com/nipy/nipype/zipball/master>`_ `tar
 <http://github.com/nipy/nipype/tarball/master>`_]

doc/users/plugins.rst

@@ -9,7 +9,7 @@ available plugins allow local and distributed execution of workflows and
 debugging. Each available plugin is described below.
 
 Current plugins are available for Linear, Multiprocessing, IPython_ distributed
-processing platforms and for direct processing on SGE_, PBS_, Condor_, and LSF_. We
+processing platforms and for direct processing on SGE_, PBS_, HTCondor_, and LSF_. We
 anticipate future plugins for the Soma_ workflow.
 
 .. note::
@@ -34,7 +34,7 @@ Optional arguments::
 .. note::
 
    Except for the status_callback, the remaining arguments only apply to the
-   distributed plugins: MultiProc/IPython(X)/SGE/PBS/Condor/LSF
+   distributed plugins: MultiProc/IPython(X)/SGE/PBS/HTCondor/HTCondorDAGMan/LSF
 
 For example:
 
@@ -71,11 +71,17 @@ a local system.
 
 Optional arguments::
 
-  n_procs :  Number of processes to launch in parallel
+  n_procs :  Number of processes to launch in parallel, if not set number of 
+  processors/threads will be automatically detected
 
 To distribute processing on a multicore machine, simply call::
 
-  workflow.run(plugin='MultiProc', plugin_args={'n_procs' : 2})
+  workflow.run(plugin='MultiProc')
+
+This will use all available CPUs. If on the other hand you would like to restrict
+the number of used resources (to say 2 CPUs), you can call::
+
+  workflow.run(plugin='MultiProc', plugin_args={'n_procs' : 2}
 
 IPython
 -------
@@ -142,27 +148,71 @@ Optional arguments::
   template: custom template file to use
   bsub_args: any other command line args to be passed to bsub.
 
-Condor
-------
+HTCondor
+--------
+
+DAGMan
+~~~~~~
+
+With its DAGMan_ component HTCondor_ (previously Condor) allows for submitting
+entire graphs of dependent jobs at once. With the ``CondorDAGMan`` plug-in
+Nipype can utilize this functionality to submit complete workflows directly and
+in a single step.  Consequently, and in contrast to other plug-ins, workflow
+execution returns almost instantaneously -- Nipype is only used to generate the
+workflow graph, while job scheduling and dependency resolution are entirely
+managed by HTCondor_.
+
+Please note that although DAGMan_ supports specification of data dependencies
+as well as data provisioning on compute nodes this functionality is currently
+not supported by this plug-in. As with all other batch systems supported by
+Nipype, only HTCondor pools with a shared file system can be used to process
+Nipype workflows.
+
+Workflow execution with HTCondor DAGMan is done by calling::
+
+       workflow.run(plugin='CondorDAGMan')
+
+Job execution behavior can be tweaked with the following optional plug-in
+arguments::
+
+  template : submit spec template to use for job submission. The template
+             all generated submit specs are appended to this template. This
+             can be a str or a filename.
+  submit_specs : additional submit specs that are appended to the generated
+                 submit specs to allow for overriding or extending the defaults.
+                 This can be a str or a filename.
+  dagman_args : arguments to be prepended to the job execution script in the
+                dagman call
+
+Please see the `HTCondor documentation`_ for details on possible configuration
+options and command line arguments.
+
+``qsub`` emulation
+~~~~~~~~~~~~~~~~~~
+
+.. note::
+
+  This plug-in is deprecated and users should migrate to the more robust and
+  more versatile ``CondorDAGMan`` plug-in.
 
-Despite the differences between Condor and SGE-like batch systems the plugin
-usage (incl. supported arguments) is almost identical. The Condor plugin relies
-on a ``qsub`` emulation script for Condor, called ``condor_qsub`` that can be
+Despite the differences between HTCondor and SGE-like batch systems the plugin
+usage (incl. supported arguments) is almost identical. The HTCondor plugin relies
+on a ``qsub`` emulation script for HTCondor, called ``condor_qsub`` that can be
 obtained from a `Git repository on git.debian.org`_. This script is currently
-not shipped with a standard Condor distribution, but is included in the Condor
+not shipped with a standard HTCondor distribution, but is included in the HTCondor
 package from http://neuro.debian.net. It is sufficient to download this script
 and install it in any location on a system that is included in the ``PATH``
 configuration.
 
 .. _Git repository on git.debian.org: http://anonscm.debian.org/gitweb/?p=pkg-exppsy/condor.git;a=blob_plain;f=debian/condor_qsub;hb=HEAD
 
-Running a workflow in a Condor pool is done by calling::
+Running a workflow in a HTCondor pool is done by calling::
 
        workflow.run(plugin='Condor')
 
 The plugin supports a limited set of qsub arguments (``qsub_args``) that cover
 the most common use cases. The ``condor_qsub`` emulation script translates qsub
-arguments into the corresponding Condor terminology and handles the actual job
+arguments into the corresponding HTCondor terminology and handles the actual job
 submission. For details on supported options see the manpage of ``condor_qsub``.
 
 Optional arguments::
@@ -176,4 +226,6 @@ Optional arguments::
 .. _Soma: http://brainvisa.info/soma/soma-workflow/
 .. _PBS: http://www.clusterresources.com/products/torque-resource-manager.php
 .. _LSF: http://www.platform.com/Products/platform-lsf
-.. _Condor: http://www.cs.wisc.edu/condor/
+.. _HTCondor: http://www.cs.wisc.edu/htcondor/
+.. _DAGMan: http://research.cs.wisc.edu/htcondor/dagman/dagman.html
+.. _HTCondor documentation: http://research.cs.wisc.edu/htcondor/manual