Add commonly-used features to utils about astroquery

[jdnc]

I could take a shot at this. One point on which I am a bit confused is that when should the astroquery.utils.progressbar.chunk_read() be preferred over the generic astropy.utils.data.get_readable_fileobj() ?

[keflavich]

Unfortunately, that's not entirely clear right now. I think we should rebuild astroquery.utils.progressbar to use requests, then it will be preferred over get_readable_fileobj

[keflavich]

I should clarify: I think we should prefer astroquery.utils.get_file_from_url over aud.get_readable_fileobj in all astroquery tools, but astroquery.utils.download_file should probably use get_readable_fileobj internally for now, with a goal to shift to a requests-based cached download tool at a later date.

[keflavich]

get_file_from_url should be relatively easy: I think it should be a thin wrapper around get_readable_fileobj, ideally with an option to save the file to disk somewhere (but adding this feature would require changes upstream in get_readable_fileobj so that the tempfile that is created is not deleted).

[keflavich]

@jdnc - please do take a shot at this! I'm not sure we'll understand all of the possible issues until there's some code in place.

[jdnc]

Right I am working on this right now - i.e. a generic get_file_from_url. Should we leave it to the caller to decide whether the returned object is a fitsfile, votable, etc and parse/validate it in the caller (and not here)? This is because for instance in the ned.core, an additional workaround needs to be used before the votable can be parsed correctly by astropy.io.votable. Also what about services like ukidss in which we can retrieve the url via an authenticated session request only?.

[keflavich]

We'll make separate functions to parse downloaded data into table/fits form, so individual functions can work around it. As for authentication, we'll need to look at that more closely... maybe the current solution is best, but perhaps there's a better way. Don't worry about that case for now.

[jdnc]

so I have had a first shot at righting this function. It can be found here https://gist.github.com/jdnc/1b3b41657766a5ba0cc1. Is this what was required?

[keflavich]

Yes, pretty much, though line 88 should probably be unindented. I think it may also be wise to have some permissions checking - perhaps wrap the whole "save" block in a try/except so that if writing to disk fails, the data is still returned and accessible

[jdnc]

oh! yes of course - so updated the gist anyways