Skip to content

Fix astropy-helpers in master - #4179

Merged
embray merged 2 commits into
astropy:masterfrom
embray:build/fix-astropy-helpers-bootstrap
Sep 23, 2015
Merged

embray merged 2 commits into
astropy:masterfrom
embray:build/fix-astropy-helpers-bootstrap

Conversation

@embray

@embray embray commented Sep 22, 2015

Copy link
Copy Markdown
Member

This fixes the issue I brought up on the mailing list yesterday (or at least works around it). This will be needed for any code that uses the latest version of astropy-helpers.

Fix to make sure that the _ASTROPY_SETUP_ global is set very early on in astropy_helpers itself. This makes up for a bug introduced in astropy/astropy-helpers#184 where astropy_helpers.command.test attempts to import astropy (just to check whether a class is importable) but that causes things to go haywire if _ASTROPY_SETUP_ hasn't been set yet.

@embray embray added 🔥 Critical Affects-dev PRs and issues that do not impact an existing Astropy release zzz 💤 astropy-helpers archived: PRs and issues related to astropy-helpers build labels Sep 22, 2015
@embray embray added this to the v1.1.0 milestone Sep 22, 2015
@embray
embray force-pushed the build/fix-astropy-helpers-bootstrap branch from d158a24 to 538f815 Compare September 22, 2015 16:45
@embray

embray commented Sep 22, 2015

Copy link
Copy Markdown
Member Author

Rebased after updating the submodule to include astropy/astropy-helpers@2f58cbe

@embray

embray commented Sep 22, 2015

Copy link
Copy Markdown
Member Author

Seeing some better luck with this so far fingers crossed

@embray

embray commented Sep 22, 2015

Copy link
Copy Markdown
Member Author

No, a5b1982 didn't fix it :/

@embray
embray force-pushed the build/fix-astropy-helpers-bootstrap branch from a5b1982 to 3cdab87 Compare September 22, 2015 20:57
@embray

embray commented Sep 22, 2015

Copy link
Copy Markdown
Member Author

Rolled back a5b1982 for a couple reasons. For one, it didn't fix the issue. And for another I'm pretty sure, after conferring with @astrofrog, that the problem is actually in a recent update to the conda package for 'wheel', and not anything having to do with the original issue this PR was intended to fix.

@embray

embray commented Sep 23, 2015

Copy link
Copy Markdown
Member Author

Going to rebase now on #4180

@embray
embray force-pushed the build/fix-astropy-helpers-bootstrap branch from 3cdab87 to 4e66187 Compare September 23, 2015 14:04
@embray

embray commented Sep 23, 2015

Copy link
Copy Markdown
Member Author

Still got

/home/travis/build/astropy/astropy/docs/wcs/index.rst:238: WARNING: Exception occurred in plotting index-1

 from /home/travis/build/astropy/astropy/docs/wcs/index.rst:

Traceback (most recent call last):

  File "/home/travis/miniconda/envs/test/lib/python2.7/site-packages/matplotlib/sphinxext/plot_directive.py", line 506, in run_code

    six.exec_(code, ns)

  File "/home/travis/miniconda/envs/test/lib/python2.7/site-packages/six.py", line 672, in exec_

    exec("""exec _code_ in _globs_, _locs_""")

  File "<string>", line 1, in <module>

  File "<string>", line 12, in <module>

  File "/home/travis/miniconda/envs/test/lib/python2.7/site-packages/matplotlib/figure.py", line 946, in add_subplot

    self, *args, **kwargs)

  File "/home/travis/miniconda/envs/test/lib/python2.7/site-packages/matplotlib/projections/__init__.py", line 100, in process_projection_requirements

    projection_class, extra_kwargs = projection._as_mpl_axes()

  File "/home/travis/build/astropy/astropy/build/lib.linux-x86_64-2.7/astropy/wcs/wcs.py", line 2950, in _as_mpl_axes

    raise ImportError("Using WCS instances as Matplotlib projections "

ImportError: Using WCS instances as Matplotlib projections requires the WCSAxes package to be installed. See http://wcsaxes.readthedocs.org for more details.

although WCSAxes appears to have installed correctly...

@embray

embray commented Sep 23, 2015

Copy link
Copy Markdown
Member Author

Weird. I can reproduce this locally. In a normal interpreter prompt I can import wcsaxes fine, but then it fails when running the docs build. Possibly something strange having to do with the way the plot directive execs the plot code (though if it's using exec it should be from within the same interpreter, and hence have all the same imports available...)

@embray

embray commented Sep 23, 2015

Copy link
Copy Markdown
Member Author

I see now. It has something to do with _ASTROPY_SETUP_. That's of course relevant to this workaround...

… in astropy_helpers itself. This makes up for a bug introduced in astropy/astropy-helpers#184 where astropy_helpers.command.test attempts to import astropy (just to check whether a class is importable) but that causes things to go haywire if _ASTROPY_SETUP_ hasn't been set yet.
… that _ASTROPY_SETUP_ is set. We only actually use the astropy module itself in one place in this setup.py anyways.
@embray
embray force-pushed the build/fix-astropy-helpers-bootstrap branch from 4e66187 to d001562 Compare September 23, 2015 16:23
embray added a commit that referenced this pull request Sep 23, 2015
@embray
embray merged commit 23f99b3 into astropy:master Sep 23, 2015
@embray
embray deleted the build/fix-astropy-helpers-bootstrap branch September 23, 2015 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Affects-dev PRs and issues that do not impact an existing Astropy release build 🔥 Critical zzz 💤 astropy-helpers archived: PRs and issues related to astropy-helpers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant