Add env variable and user config option to suppress packaging warnings

[ThePrez]

Summary

This PR adds a new env variable QISKIT_SUPPRESS_PACKAGING_WARNINGS and a
matching user config file option suppress_packaging_warnings which can be used to optionally
suppress the regular warnings about aer and/or ibmq-provider missing at import time. This strikes
a balance between telling users who potentially have a packaging issue that would otherwise go
by unnoticed and giving users who are intentionally (or unable to) install the components the ability to disable the warnings.

Details and comments

Some platforms (in my case IBM i) cannot reliably build newer versions qiskit-aer due to new dependencies, etc. In my case, I want to pursue qiskit use with only terra (and show others), but the constant RuntimeWarning is an annoyance easily (incorrectly) perceived as an error.

In short, I'd like a way to suppress that warning, and I think an environment variable is a cheap and easy way to do so.

Co-authored-by: Matthew Treinish mtreinish@kortar.org

[mtreinish]

I'm not opposed to having a flag to do this. But before we add it I'm curious does the example from the documentation at the end of the terra from source section (https://qiskit.org/documentation/contributing_to_qiskit.html#installing-terra-from-source work) for your use case?

That being said I think if we want to make this more easily configurable. You raise a good point about compiling aer, aer's build system makes it hard to build from source in a lot of environments. I think we should change the flag to be QISKIT_SUPPRESS_WARNINGS or QISKIT_SUPPRESS_PACKAGING_WARNINGS and apply it to ibmq too. We also should add the option to the qiskit user config file: https://github.com/Qiskit/qiskit-terra/blob/master/qiskit/user_config.py so people can set once.

[ThePrez]

Yes, that example code using the warning filter does address my use case. I'm happy with that since it is documented (I didn't want to blindly apply a warnings filter and didn't read the doc).

I do like both of your suggestions. QISKIT_SUPPRESS_PACKAGING_WARNINGS seems a good choice, and adding to the user_config certainly makes sense. Of course, I'm not sure how many people are out there building terra and aer from source. If I'm the only one who cares, we can table the idea. Or, I can clean it up and make the necessary changes.

[mtreinish]

Yeah, I think it's worthwhile even if it's not for the majority of users I think that there is a big enough set of users where this matters.

I actually hit this personally because on one of my systems I'm fighting a packaging issue with ibmq and the import doesn't ever work which always emits a warning. So having a way to filter it easily outside of the calling script would be handy.

I think that this will make the developer experience a bit more friendly. The warnings were mostly added as a stopgap against frequent bug filings because of the fragility of python packaging, especially around namespace packages. But, that was a conscious tradeoff of annoying people with more specialized use cases. So having a builtin workaround for that is a good idea.

[ajavadia]

@ThePrez is there any update on this?

[ThePrez]

Sorry. I haven't had time to circle back around and finish this up in other places. I probably won't be able to dig back into this for another couple weeks. We can let simmer, or we can merge the trivial changes in this PR and keep a work item open for the qiskit user config file and also ibmq if needed.

[mtreinish]

@ThePrez I went ahead and updated this, it's been sitting idle for several months and we'd really like to get this feature in the next release. It has come up several times that using just filter warnings isn't flexible enough for several use cases.

[kdk]

Is it worth specifying the behavior if the user provides conflicting config and an env values? (Right now, I think if either are 'Y'/'y'/True, the message will be suppressed, but the ENV variable could take precedence over the config value or vice versa. I don't know if there's precedent for other config values.)

[mtreinish]

That's a fair point, the env variable should take precedence over the user config file. We don't have it with env vars anywhere but it does exist for the parameters (like visualization backend)

[mtreinish]

@kdk ok I updated the logic in 4f5f8ea the env var set to N will override the user config file setting