starred/spotipy

Fork 0

mirror of https://github.com/spotipy-dev/spotipy.git synced 2026-04-27 00:25:54 +03:00

[GH-ISSUE #478] Importing spotipy breaks logs even on simple code #282

New issue

Closed

opened 2026-02-27 23:21:46 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 23:21:46 +03:00

Owner

Originally created by @zambam5 on GitHub (Apr 24, 2020).
Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/478

After moving machines and updating things, I noticed that when I use Spotipy it breaks any sort of logging that I've been doing. This is basic example where if I don't import Spotipy, everything works as expected, but if I do it does not log. This is in Python 3.8.2

import logging
import spotipy

logging.basicConfig(level=logging.DEBUG)
mylogger = logging.getLogger(__name__)
handler = logging.FileHandler('test.log', mode='w')
formatter = logging.Formatter('''%(asctime)s -
                              %(name)s - %(levelname)s - %(message)s''')
handler.setFormatter(formatter)
mylogger.addHandler(handler)
mylogger.info('test')```

Originally created by @zambam5 on GitHub (Apr 24, 2020). Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/478 After moving machines and updating things, I noticed that when I use Spotipy it breaks any sort of logging that I've been doing. This is basic example where if I don't import Spotipy, everything works as expected, but if I do it does not log. This is in Python 3.8.2 ```python import logging import spotipy logging.basicConfig(level=logging.DEBUG) mylogger = logging.getLogger(__name__) handler = logging.FileHandler('test.log', mode='w') formatter = logging.Formatter('''%(asctime)s - %(name)s - %(levelname)s - %(message)s''') handler.setFormatter(formatter) mylogger.addHandler(handler) mylogger.info('test')```

kerem

2026-02-27 23:21:46 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@ritiek commented on GitHub (Apr 24, 2020):

It seems the regression was caused in c6de8dc713. I'm not sure why this change would break logging.

@ritiek commented on GitHub (Apr 24, 2020): It seems the regression was caused in c6de8dc7131e5165b5d9cf2c266444a6f2b6c68d. I'm not sure why this change would break logging.

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@ritiek commented on GitHub (Apr 24, 2020):

It looks like external scripts are unable to override this logging configuration which has once been set in spotipy.

@ritiek commented on GitHub (Apr 24, 2020): It looks like external scripts are unable to override this logging configuration which has once been set in spotipy.

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@stephanebruckert commented on GitHub (Apr 26, 2020):

I will have a look this week. I initially added github.com/plamere/spotipy@c6de8dc713 because tests were failing. Perhaps I should just have added logging.basicConfig() in the tests rather than in the code? The thing is that it should also work for anyone without specifying logging.basicConfig() in their code

@stephanebruckert commented on GitHub (Apr 26, 2020): I will have a look this week. I initially added https://github.com/plamere/spotipy/commit/c6de8dc7131e5165b5d9cf2c266444a6f2b6c68d because tests were failing. Perhaps I should just have added `logging.basicConfig()` in the tests rather than in the code? The thing is that it should also work for anyone without specifying `logging.basicConfig()` in their code

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@Beahmer89 commented on GitHub (Apr 26, 2020):

I was just about to file a bug about this, but generally libraries should not initialize the logging system. That should be left to the underlying application that is using the library. Libraries like requests and psycopg2 follow this pattern.

As far as tests failing, the tests seemed to have been passing when I submitted the work for my PR to add the logging here. So if they were breaking it might have been something else that was added with later changes. But I just pulled down the latest code down and the tests seem to pass. Should be safe to remove.

@Beahmer89 commented on GitHub (Apr 26, 2020): I was just about to file a bug about this, but generally libraries should not initialize the logging system. That should be left to the underlying application that is using the library. Libraries like requests and psycopg2 follow this pattern. As far as tests failing, the tests seemed to have been passing when I submitted the work for my PR to add the logging [here](https://github.com/plamere/spotipy/pull/461). So if they were breaking it might have been something else that was added with later changes. But I just pulled down the latest code down and the tests seem to pass. Should be safe to remove.

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@stephanebruckert commented on GitHub (Apr 26, 2020):

Alright I found that this error only happens with python2

test_track_bad_id (integration.test_user_endpoints.SpotipyLibraryApiTests) ... No handlers could be found for logger "spotipy.client"
ok

but it's all good with python3

test_track_bad_id (integration.test_user_endpoints.SpotipyLibraryApiTests) ... HTTP Error for GET to https://api.spotify.com/v1/tracks/BadID123 returned 400 due to invalid id
ok

So let's not worry about it unless someone complains about it. I'm going to merge your PR now @Beahmer89, thanks for that! also thanks for reporting @zambam5

@stephanebruckert commented on GitHub (Apr 26, 2020): Alright I found that this error only happens with python2 > test_track_bad_id (integration.test_user_endpoints.SpotipyLibraryApiTests) ... No handlers could be found for logger "spotipy.client" ok but it's all good with python3 > test_track_bad_id (integration.test_user_endpoints.SpotipyLibraryApiTests) ... HTTP Error for GET to https://api.spotify.com/v1/tracks/BadID123 returned 400 due to invalid id ok So let's not worry about it unless someone complains about it. I'm going to merge your PR now @Beahmer89, thanks for that! also thanks for reporting @zambam5

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@stephanebruckert commented on GitHub (Apr 26, 2020):

Released in 2.12.0, @zambam5 feel free to upgrade

@stephanebruckert commented on GitHub (Apr 26, 2020): Released in 2.12.0, @zambam5 feel free to upgrade

kerem commented

2026-02-27 23:21:47 +03:00

Author

Owner

@Beahmer89 commented on GitHub (Apr 26, 2020):

huh, thats crazy that that only happens in python2. Interesting find @stephanebruckert! I was only running my tests in python3, but will have to mess around with a python2.7 env.

@Beahmer89 commented on GitHub (Apr 26, 2020): huh, thats crazy that that only happens in python2. Interesting find @stephanebruckert! I was only running my tests in python3, but will have to mess around with a python2.7 env.