This won't test against @astrofrog's .travis PR right now - I'm inclined to merge this, then ask Tom to merge/rebase against master, then see if we can get all the .travis builds working. Or, alternatively, we could merge the .travis PR (which seems fine) and rebase this against it. Which do you prefer?

I'll let both travis builds finish (a few hours) then make some decisions and see if we can't get both of these merged.

@keflavich I just saw #16 . You can close that one when you merge this.

I think that you can merge #64 first, that way when this gets merged in it will get tested and we can then address any failures.

@cdeil - would it be easy for you to rebase and push so we can re-test?

Merged #64, so rebase against master now?

Rebased.

I restarted the travis build; I think on a rebase, there's no travis build trigger

@keflavich Eventually there is a travis build when a rebase is pushed, but sometimes it doesn't start right away and it only shows up on the github UI once it's finished.

@keflavich @astrofrog Do you understand the travis test failures here ?

E.g. https://travis-ci.org/astropy/astroquery/jobs/6316304 shows the KeyError with threading.
And https://travis-ci.org/astropy/astroquery/jobs/6316302 shows a Python 3 string / unicode problem.

No, @astrofrog? I posted the same issue on #64, so I don't think it's an issue with this PR - I'm happy to merge this now.

I'm just going to quickly diagnose the issue with python 3 string/unicode

OK, @astrofrog, merge when you're satisfied then

The unicode/string issue is actually a big in the error display in astropy's master (and 0.2.1) but if I use a locally fixed version, building's @cdeil's branch gives:

Stdout:
You need the 'mechanize' module

Stderr:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/astropy/config/configuration.py", line 646, in generate_all_config_items
    for cfgitem in get_config_items(nm).values():
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/astropy/config/configuration.py", line 533, in get_config_items
    __import__(packageormod)
  File "./astroquery/tests/test_ukidss.py", line 1, in <module>
    from astroquery import ukidss
  File "./astroquery/ukidss/__init__.py", line 1, in <module>
    from .ukidss import *
  File "./astroquery/ukidss/ukidss.py", line 11, in <module>
    import htmllib
ImportError: No module named 'htmllib'

which is the source of the error. Actually I see the same issue in master, so I guess this PR isn't the cause of the error.

The threading error is actually a symptom of another failure - that there are warnings in the docs build. So if you can get rid of those warnings, the threading error will disappear.

I think we should try and fix these before merging, but I'm out of time. Just for info, to get the proper error for the first case, you need to be running Python 3, and change

        msg = ('Generation of default configuration item failed! Stdout '
               'and stderr are shown below.\n'
               'Stdout:\n{stdout}\nStderr:\n{stderr}').decode('UTF-8')

to

        msg = ('Generation of default configuration item failed! Stdout '
               'and stderr are shown below.\n'
               'Stdout:\n{stdout}\nStderr:\n{stderr}')

in astropy/setup_helpers.py.

@astrofrog - have you promoted these to astropy issues?

I'd prefer to merge this, then have other issues pointing back to these problems, since this PR is not responsible for either of those bugs (I think #64 is the one actually responsible).

The doc errors also deserve their own issue.

All that said, I'll leave it open for now - I'm not really in a huge hurry, I just think this is not the right forum for those issues.

@keflavich - just to clarify, the bugs in Astropy (which I think are both reported, will check tomorrow) are hiding two real issues in the package, but feel free to address them in a separate pull request. But you should be able to fix them here such that the tests pass, the bugs in Astropy are just in the actual errors themselves, not the fact an error is raised.

Since nothing in this PR breaks builds, but removing coords may fix other builds (got some SWIG errors in some builds because of this), I'm going to merge it. Further discussion of the errors @astrofrog noted should go in #70