Logging basicConfig() breaks my loggers

[AsteroidOrangeJuice]

I've recently encountered a problem caused by the usage of logging.basicConfig() in this library. Normally, this call should be made at the entry point to the application, but it was randomly called halfway during my application's initialization, by this library. It should be removed.

[AsteroidOrangeJuice]

Here's one of the two commits adding it: b24c884

This lines up with my experience - I did not have problems with pypi version 1.0.7 but 1.1.0 did break me. I had to roll back.

[wfordh]

I've recently encountered a problem caused by the usage of logging.basicConfig() in this library. Normally, this call should be made at the entry point to the application, but it was randomly called halfway during my application's initialization, by this library. It should be removed.

Sorry for the long wait here, but thank you for bringing this up and apologies for causing the error with that commit. I'm not super familiar with packages in general but have been trying to read up on logging, entry points, and warnings. It seems like switching from logging.basicConfig() to warnings.warn() might do the trick, but I'm not sure how to test that.

If you have any suggestions, I'm all ears! Otherwise I'll try to test that out locally and see if I can get it fixed soon.

[AsteroidOrangeJuice]

I believe literally commenting it out is sufficient:

416b085

Whatever application you are using this library in should be responsible for calling logging.basicConfig(level=logging.WARN) so your application can choose what log level it wants.

[wfordh]

Yes, commenting it out would work but I would like users to still be aware of what the messages are conveying. I think where I messed up was using logging.basicConfig() rather than logging.getLogger(__name__) in those files and will push that fix shortly.

Could you share which Python version you are using and a code snippet showing what your app is doing so that I can test out the changes locally before opening the PR?