FIX: Replace deprecated HasTraits.get with trait_get

[oesteban]

Deprecation mark: https://github.com/enthought/traits/blob/a99b3f64d50c5f7f28ffc01bf69419b061f9e976/traits/has_traits.py#L1481

Fixes the following deprecation warning:

nipype/nipype/interfaces/base/specs.py:160: DeprecationWarning: use "HasTraits.trait_get" instead
  out = super(BaseTraitedSpec, self).get(**kwargs)

This warning has started to appear recently, traits must have gotten a major update.

[effigies]

HasTraits.trait_get has been around since at least traits 3.0, so I don't think we need to check for an AttributeError here.

On the other hand, I do think we should conform to the API and move to trait_get(), ourselves. Maybe just make a copy with trait_get, so that get() will still raise DeprecationWarnings? Alternatively, we could have both call trait_get, and raise our own deprecation warnings, so that our timeline isn't dictated by traits'.

[oesteban]

Instead of removing the AttributeError check, I could raise a Warning asking the user to update traits. Even though HasTraits.trait_get has been there for long, I started to see these warnings only recently, so I guess the deprecation was included later (?).

Regarding conforming our API to the traits', I'm not sure we want to change that. Nipype usually prefers the properties to access the inputs/outputs so no need for getter/setters. WDYT @satra?

[oesteban]

Sorry, ref. the first comment: the idea would be removing the except AttributeError completely in nipype 2.0.

[effigies]

Our minimum version is 4.6. There is no danger of someone hitting the AttributeError.

Regarding conforming our API to the traits', I'm not sure we want to change that. Nipype usually prefers the properties to access the inputs/outputs so no need for getter/setters.

Something like this is a pretty common idiom in nipype:

def _list_outputs(self):
    outputs = self._outputs().get()
    ...

[satra]

i think we could conform to trait_get but continue supporting get in the 1.x series.