Skip to content

Doctests fail with pytest 3.0.5 #5670

Description

@olebole

When I run the tests with an external pytest 3.0.5, I get many errors in the doctests:

$ fgrep FAILED ../python-astropy_1.3-3_amd64.build
../docs/known_issues.rst::known_issues.rst FAILED
../docs/warnings.rst::warnings.rst FAILED
../docs/analytic_functions/index.rst::index.rst FAILED
../docs/config/index.rst::index.rst FAILED
../docs/constants/index.rst::index.rst FAILED
../docs/coordinates/angles.rst::angles.rst FAILED
../docs/coordinates/frames.rst::frames.rst FAILED
../docs/coordinates/index.rst::index.rst FAILED
../docs/coordinates/inplace.rst::inplace.rst FAILED
../docs/coordinates/remote_methods.rst::remote_methods.rst FAILED
../docs/coordinates/representations.rst::representations.rst FAILED
../docs/coordinates/skycoord.rst::skycoord.rst FAILED
../docs/coordinates/solarsystem.rst::solarsystem.rst FAILED
../docs/coordinates/transforming.rst::transforming.rst FAILED
../docs/cosmology/index.rst::index.rst FAILED
../docs/development/codeguide.rst::codeguide.rst FAILED
../docs/development/docrules.rst::docrules.rst FAILED
FAILED
../docs/io/unified.rst::unified.rst FAILED
../docs/io/ascii/fixed_width_gallery.rst::fixed_width_gallery.rst FAILED
../docs/io/ascii/index.rst::index.rst FAILED
../docs/io/ascii/read.rst::read.rst FAILED
../docs/io/fits/index.rst::index.rst FAILED
../docs/io/fits/appendix/faq.rst::faq.rst FAILED
../docs/io/fits/appendix/header_transition.rst::header_transition.rst FAILED
../docs/io/fits/appendix/history.rst::history.rst FAILED
../docs/io/fits/usage/headers.rst::headers.rst FAILED
../docs/io/fits/usage/image.rst::image.rst FAILED
../docs/io/fits/usage/table.rst::table.rst FAILED
../docs/io/fits/usage/unfamiliar.rst::unfamiliar.rst FAILED
../docs/io/fits/usage/verification.rst::verification.rst FAILED
../docs/io/votable/index.rst::index.rst FAILED
../docs/modeling/compound-models.rst::compound-models.rst FAILED
../docs/modeling/fitting.rst::fitting.rst FAILED
../docs/modeling/index.rst::index.rst FAILED
../docs/modeling/models.rst::models.rst FAILED
../docs/modeling/parameters.rst::parameters.rst FAILED
../docs/nddata/nddata.rst::nddata.rst FAILED
../docs/nddata/utils.rst::utils.rst FAILED
../docs/table/access_table.rst::access_table.rst FAILED
../docs/table/construct_table.rst::construct_table.rst FAILED
../docs/table/index.rst::index.rst FAILED
../docs/table/indexing.rst::indexing.rst FAILED
../docs/table/io.rst::io.rst FAILED
../docs/table/masking.rst::masking.rst FAILED
../docs/table/mixin_columns.rst::mixin_columns.rst FAILED
../docs/table/modify_table.rst::modify_table.rst FAILED
../docs/table/operations.rst::operations.rst FAILED
../docs/table/pandas.rst::pandas.rst FAILED
../docs/time/index.rst::index.rst FAILED
../docs/units/decomposing_and_composing.rst::decomposing_and_composing.rst FAILED
../docs/units/equivalencies.rst::equivalencies.rst FAILED
../docs/units/format.rst::format.rst FAILED
../docs/units/index.rst::index.rst FAILED
../docs/units/logarithmic_units.rst::logarithmic_units.rst FAILED
../docs/units/quantity.rst::quantity.rst FAILED
../docs/units/standard_units.rst::standard_units.rst FAILED
../docs/visualization/normalization.rst::normalization.rst FAILED
../docs/vo/conesearch/client.rst::client.rst FAILED
../docs/vo/conesearch/index.rst::index.rst FAILED
../docs/vo/conesearch/validator.rst::validator.rst FAILED
../docs/vo/samp/example_clients.rst::example_clients.rst FAILED
../docs/vo/samp/example_hub.rst::example_hub.rst FAILED
../docs/vo/samp/example_table_image.rst::example_table_image.rst FAILED
../docs/wcs/index.rst::index.rst FAILED
../docs/wcs/note_sip.rst::note_sip.rst FAILED
../docs/whatsnew/0.4.rst::0.4.rst FAILED
../docs/whatsnew/1.0.rst::1.0.rst FAILED
../docs/whatsnew/1.1.rst::1.1.rst FAILED
../docs/whatsnew/1.3.rst::1.3.rst FAILED

There seem to be several causes: sometimes pytest detects differences where they are none:

_________________________ [doctest] standard_units.rst _________________________
028 `~astropy.units.CompositeUnit`. In most cases, one does not need
029 to worry about the various kinds of unit classes unless one wants to
030 design a more complex case.
031 
032 There are many units already predefined in the module. One may use the
033 `~astropy.units.core.UnitBase.find_equivalent_units` method to list
034 all the existing predefined units of a given type::
035 
036   >>> from astropy import units as u
037   >>> u.g.find_equivalent_units()
Differences (unified diff with -expected +actual):
    @@ -1,3 +1,3 @@
    -  Primary name | Unit definition | Aliases
    +  Primary name | Unit definition | Aliases
     [
       M_e          | 9.10938e-31 kg  |                                  ,

/tmp/astropy-test-FtSQid/docs/units/standard_units.rst:37: DocTestFailure

Sometimes the tests fail because of unavailable modules (they are unavaliable, but don't let the tests fail with the builtin version):

______________________________ [doctest] 1.1.rst _______________________________
135 :meth:`~astropy.table.Table.from_pandas`.
136 
137 To demonstrate these, we can create a simple table which we convert to a
138 pandas `DataFrame`_::
139 
140     >>> from astropy.table import Table
141     >>> t = Table()
142     >>> t['a'] = [1, 2, 3, 4]
143     >>> t['b'] = ['a', 'b', 'c', 'd']
144     >>> df = t.to_pandas()
UNEXPECTED EXCEPTION: ImportError('No module named pandas',)
Traceback (most recent call last):

  File "/usr/lib/python2.7/doctest.py", line 1315, in __run
    compileflags, 1) in test.globs

  File "<doctest 1.1.rst[4]>", line 1, in <module>

  File "astropy/table/table.py", line 2584, in to_pandas
    from pandas import DataFrame

ImportError: No module named pandas

/tmp/astropy-test-FtSQid/docs/whatsnew/1.1.rst:144: UnexpectedException

sometimes they try to connect with the outside world:

_____________________________ [doctest] index.rst ______________________________
058 ---------------
059 
060 This section only contains minimal examples showing how to perform
061 basic Cone Search.
062 
063 >>> from astropy.vo.client import conesearch
064 
065 List the available Cone Search catalogs:
066 
067 >>> conesearch.list_catalogs()
UNEXPECTED EXCEPTION: URLError(error(111, 'Connection refused'),)
Traceback (most recent call last):

  File "/usr/lib/python2.7/doctest.py", line 1315, in __run
    compileflags, 1) in test.globs

  File "<doctest index.rst[1]>", line 1, in <module>

  File "astropy/vo/client/conesearch.py", line 321, in list_catalogs
    return vos_catalog.list_catalogs(conf.conesearch_dbname, **kwargs)
[...]
  File "astropy/utils/data.py", line 197, in get_readable_fileobj
    timeout=remote_timeout)

  File "astropy/utils/data.py", line 1097, in download_file
    raise e

URLError: <urlopen error [Errno 111] Connection refused>

/tmp/astropy-test-FtSQid/docs/vo/conesearch/index.rst:67: UnexpectedException

sometimes a calculation goes wrong:

______________________________ [doctest] 1.0.rst _______________________________
056 coordinates.  This means `~astropy.coordinates` can now be used for planning
057 observations.  For example::
058 
059     >>> from astropy import units as u
060     >>> from astropy.time import Time
061     >>> from astropy.coordinates import SkyCoord, EarthLocation, AltAz
062     >>> greenwich = EarthLocation(lat=51.477*u.deg,lon=0*u.deg)
063     >>> albireo = SkyCoord('19h30m43.2805s +27d57m34.8483s')
064     >>> altaz = albireo.transform_to(AltAz(location=greenwich, obstime=Time('2014-6-21 0:00')))
065     >>> print altaz.alt, altaz.az
Expected:
    60d32m28.4576s 133d45m36.4967s
Got:
    60d32m28.4579s 133d45m36.4967s

and there are many other problems as well. Looks like some compatibility problem?

I have no history for this problem, since by mistake we currently use the built-in pytest. This however fails with astroplan.
Any ideas?

Activity

  1. bsipocz commented on Jan 6, 2017

    @bsipocz
    Member

    Some of this may relate to the issue #5277, however the remote access ones are most worrying and probably unrelated to that one as you see a similar issue in #5651

  2. pllim commented on Jan 6, 2017

    @pllim
    Member

    Some work definitely needs to be done to support pytest 3.x. For now, just use pytest 2.x.

  3. olebole commented on Jan 7, 2017

    @olebole
    MemberAuthor

    The problem is that in Debian we don't have a choice, therefore I need to stay with the astropy-internal pytest (ugly and against our policy), or to disable the failing tests (ugly as well, since we disarm us there to detect problems).
    Also, at least astroplan has problems with the builtin astropy pytest.

  4. pllim commented on Jan 7, 2017

    @pllim
    Member

    @kelle and I looked into making Astropy working with pytest 3.x as AAS hack day but it appears to be a lot more complicated than I expected. It looks like the underlying pytest plugins need to be refactored to accommodate pytest 3.x changes but I am not sure how. @kelle was investigating on how to replace the deprecation warnings about yield and submitted her findings in #5678.

  5. mhvk commented on Jan 9, 2017

    @mhvk
    Contributor

    The yield tests have now all been removed (#5678 and #5682) -- the documentation failures are more puzzling; more discussion in #5277.

  6. mhvk commented on Jan 12, 2017

    @mhvk
    Contributor

    @olebole - I don't know by what time you need a fix for the upcoming freeze, but a possible fix is in #5688.

  7. olebole commented on Jan 12, 2017

    @olebole
    MemberAuthor

    Thank you! I just temporarily disabled the doctests, but I will check the PR and integrate it if it works.

  8. bsipocz commented on May 9, 2017

    @bsipocz
    Member

    @olebole - #5688 seems to fix this. Feel free to reopen if this is not the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions