[SciPy-Dev] GSoC'17 candidate - Interested in Nose to Pytest Migration.

[Pauli Virtanen]

Tue, 28 Feb 2017 00:35:04 +0300, Evgeni Burovski kirjoitti:
[clip]
>> Thoughts?
> 
> My reasoning was simple: there is already a compatibility layer of
> numpy.testing.
> 
> As soon as numpy.testing works in a virtualenv which has pytest and does
> not have nose, the scipy test suite just works, modulo maybe a handful
> of nose-isms to clean up (a stray import from nose.tools, a
> setUp/tearDown pair in a class derived from object etc). To catch those,
> we anyway need to have two parallel installations, one with nose, and
> one without, at least temporarily.
> 
> At this point we can either stop or do additional work of removing nose
> from numpy.testing, which is invisible for scipy --- because
> numpy.testing just shields it all.

I'm actually advocating for abandoning numpy.testing (ie. the test runner 
part --- the assert functions are fine). I think this is what other numpy-
dependent projects that use pytest do. Making numpy.testing test runners 
work with pytest sounds like a complication that's not really necessary, 
and adding up more things to maintain.

If we are going to port the test suite to work with pytest, I would go 
all the way. By "vanilla" pytest, I mean whatever pytest supports out of 
the box, without inventing a new framework with custom conventions.

> This of course leaves two elephants in the room:
> 
> - backwards compat for older numpy versions. A straightforward solution
> is to make a separate package, numpy-testing and mechanically import
> from it instead of numpy.testing (or make the latter import from the
> former).
> - yield based test generators.

I think the first issue goes away if we abandon numpy.testing --- the 
nose-dependent parts will retained unchanged and maybe deprecated in the 
long run, and the nose-independent parts kept.

The second issue probably doesn't --- these tests would have to be 
rewritten with the corresponding pytest-isms (fixtures afaics) in any 
case.

	Pauli