astropy / astropy/astroquery

Optional Gaia server messages?

Open
#3,196 5 comments 0 reactions 0 assignees View on GitHub
gaia
Dominant language
Python
Stars
791
Forks
451
Avg merge
1d 3h
Merged PRs (30d)
4

Description

Right now I am using `astroquery` as a dependency for a package, and have doc tests that involve my module. These occasionally break, because of gaia status messages which get printed directly to stdout.

https://github.com/astropy/astroquery/blob/ade38dc9cda548b4b86e5a7d610d7e07b4d9808d/astroquery/gaia/core.py#L1025

That's fair enough, I think most users might want to see these messages by default. However, I would personally like to switch them off. So I try using the kwarg argument to switch them off:

```
from astroquery.gaia import GaiaClass
Gaia = GaiaClass(show_server_messages=False)
```

which makes use of:

https://github.com/astropy/astroquery/blob/ade38dc9cda548b4b86e5a7d610d7e07b4d9808d/astroquery/gaia/core.py#L89

In theory that should work, but right at the bottom of the script defining the `GaiaClass` class, there is this line:

https://github.com/astropy/astroquery/blob/ade38dc9cda548b4b86e5a7d610d7e07b4d9808d/astroquery/gaia/core.py#L1048

That creates a `GaiaClass` object, and uses the default settings (i.e `show_server_message=True`). So, by time I've hit the line `from astroquery.gaia import GaiaClass` I already get the stdout message.

As a workaround I can send things to dev null for that one specific import line, but it seems to me like the `show_server_message` argument is not behaving as intended, so I thought I would create the github issue here first.

Options I can think of to fix this include be to using the python logger rather than print (then I can toggle the message on/off), have the default of the printing set by an environment level, or setting a default of `show_server_message=False`. Apologies if a discussion about this already exists.

Contributor guide

Open the contributing guide

Research direction

Start in astroquery/gaia/core.py around the GaiaClass constructor at line 89, the server-message output near line 1025, and the module-level GaiaClass instance near line 1048. Reproduce the import-time stdout message, then determine which message-control behavior the project should support. Done means importing GaiaClass does not unexpectedly print while explicit server-message behavior remains configurable.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.