[GH-ISSUE #406] Choosing a new home for Spotipy

kerem commented

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

Owner

Originally created by @felix-hilden on GitHub (Dec 19, 2019).
Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/406

Hello again! Plamere has been inactive for a long time so Spotipy has been transferred to my name on PyPI and Read The Docs. In #404 we decided to continue the development of Spotipy. Now it's time to discuss where.

Original issue: Is under development?

In August there was a long discussion in #387 on whether this project was abandoned or not. A number of alternatives were also declared as in development. I thought it would be fair to mention them here and include them in the list of considerations. In the order of announcement they were:

spotify-api by Saphyel
spotipy by felix-hilden
spotipy by Harrison97
spotipy by davidt99

The current discussion

We should discuss where the new home of Spotipy should be. That can be one of the repositories above or elsewhere if another one is announced. An appropriate time frame for the transfer should also be chosen, meaning a period where the information about the transfer is available but the package is still in its original state. The transfer is then announced in a separate issue.

State your case below. Please link to the repository, introduce it and argue why it should be chosen over other options that are presented.

Please vote or comment on versions even if you have not written one!

Originally created by @felix-hilden on GitHub (Dec 19, 2019). Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/406 Hello again! Plamere has been inactive for a long time so Spotipy has been transferred to my name on [PyPI](https://github.com/pypa/pypi-support/issues/28) and [Read The Docs](https://github.com/readthedocs/readthedocs.org/issues/6335). In #404 we decided to continue the development of Spotipy. Now it's time to discuss where. ### Original issue: Is under development? In August there was a long discussion in #387 on whether this project was abandoned or not. A number of alternatives were also declared as in development. I thought it would be fair to mention them here and include them in the list of considerations. In the order of announcement they were: - [spotify-api](https://github.com/Saphyel/spotify-api) by Saphyel - [spotipy](https://github.com/felix-hilden/spotipy) by felix-hilden - [spotipy](https://github.com/Harrison97/spotipy) by Harrison97 - [spotipy](https://github.com/davidt99/spotipy) by davidt99 ### The current discussion We should discuss where the new home of Spotipy should be. That can be one of the repositories above or elsewhere if another one is announced. An appropriate time frame for the transfer should also be chosen, meaning a period where the information about the transfer is available but the package is still in its original state. The transfer is then announced in a separate issue. State your case below. Please link to the repository, introduce it and argue why it should be chosen over other options that are presented. **Please vote or comment on versions even if you have not written one!**

kerem closed this issue

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

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 19, 2019):

spotipy - felix-hilden

I have written an updated version of the package. It's a complete client of the API in terms of authentication and endpoints, and has been in active development since August. We have an existing update plan for the event that this repository is chosen. Not to mention the cool logo :D This is the kind of code you'll be writing:

from spotipy import util, Spotify
from spotipy.scope import scopes
from spotipy.convert import to_uri

# Authenticate
cred = util.credentials_from_environment()
scope = scopes.user_library_read + scopes.user_modify_playback_state
token = util.prompt_for_user_token(*cred, scope=scope)

# Play a saved album
spotify = Spotify(token)
album = spotify.saved_albums(limit=1).items[0].album
album_uri = to_uri('album', album.id)
spotify.playback_start_context(album_uri)

Comparison with Plamere

The current version is a bare-bones client. It makes requests and returns their contents. It worked, but I didn't like they way it worked. Documentation errors and inconsistencies aside, I mainly wanted to provide some reassurance and conveniences when using the client. They are especially effective when using an IDE with some sort of autocompletion or static checking. My version is based on Plamere's, but refactored and streamlined.

Highlights

What does this request return? No sweat. It returns a response model with real attributes instead of a simple dictionary. Don't know which fields are available? All fields documented with type hints and all client return types specified. The Web API documentation itself is not the greatest, so parsing the responses into models is a good way of being sure we know what's in the box when we open it. The models can be converted back to dictionaries as well!
Which scopes do I need for my token? Easy. They're all documented in the client methods. And all available scopes are enumerated for you to browse. No more typos.
When does this token expire? NEVER! If you want it to. You can create self-refreshing tokens and forget about it.
100 % test coverage! Almost every line of the package is executed by a suite of tests, and the client is tested with the live Web API.
Awesome documentation with interesting examples and a detailed package reference.

See a more detailed list of features here.

Considering other options

None of the original candidates have received commits for the last few months, except Harrison's which after a period of inactivity since August was recently committed to a few times. Unless considerable amounts of code has simply not been pushed, I don't view them as good options.

I'd also like to address one particular version, Harrison's fork, since it is the second-most starred option. As I've stated before, I think the original code is not worth maintaining anymore. And making the same changes I've already made, refactoring and cleaning up documentation seems like a waste of effort.

I think my design and features make the package both easier and more flexible to use. So in my opinion it is much better than the original and by extension Harrison's as well, at least if he has no plans of changing it. But I can't speak for everyone. This is no smack-down argument. Whether you like my design is up to you to decide. And he could very well fix the problems I laid out for the original version. I'd love for you to pitch in Harrison! What are you planning to do with the package? Is PyPI a goal for you?

The human-side of things

I've been by far the most active person driving this issue forward and developing a new version. I'm certainly willing to extend that effort to maintaining the package. A number of helpful contributors have already provided great suggestions and bug reports, but I'd like to grow that number and perhaps add another maintainer as well. I dislike the idea of everything depending on one person.

Time-frame

I think after announcing the transfer, one month should go by before releasing the new version. I plan on making a final release of this repository's contents as discussed here. At least two weeks should go by after that release before releasing the new version.

@felix-hilden commented on GitHub (Dec 19, 2019): ### [spotipy](https://github.com/felix-hilden/spotipy) - felix-hilden I have written an updated version of the package. It's a complete client of the API in terms of authentication and endpoints, and has been in active development since August. We have an existing [update plan](https://github.com/felix-hilden/spotipy/issues/22#issuecomment-545008685) for the event that this repository is chosen. Not to mention the [cool logo](https://github.com/felix-hilden/spotipy/blob/master/docs/spotipy_logo_small.png) :D This is the kind of code you'll be writing: ```python from spotipy import util, Spotify from spotipy.scope import scopes from spotipy.convert import to_uri # Authenticate cred = util.credentials_from_environment() scope = scopes.user_library_read + scopes.user_modify_playback_state token = util.prompt_for_user_token(*cred, scope=scope) # Play a saved album spotify = Spotify(token) album = spotify.saved_albums(limit=1).items[0].album album_uri = to_uri('album', album.id) spotify.playback_start_context(album_uri) ``` #### Comparison with Plamere The current version is a bare-bones client. It makes requests and returns their contents. It worked, but I didn't like they way it worked. Documentation errors and inconsistencies aside, I mainly wanted to provide some reassurance and conveniences when using the client. They are especially effective when using an IDE with some sort of autocompletion or static checking. My version is based on Plamere's, but refactored and streamlined. #### Highlights - What does this request return? *No sweat.* It returns a response model with real attributes instead of a simple dictionary. Don't know which fields are available? All fields documented with type hints and all client return types specified. The Web API documentation itself is not the greatest, so parsing the responses into models is a good way of being sure we know what's in the box when we open it. The models can be converted back to dictionaries as well! - Which scopes do I need for my token? **Easy.** They're all documented in the client methods. And all available scopes are enumerated for you to browse. No more typos. - When does this token expire? NEVER! If you want it to. You can create self-refreshing tokens and forget about it. - 100 % test coverage! Almost every line of the package is executed by a suite of tests, and the client is tested with the live Web API. - Awesome [documentation](https://updated-spotipy-test.readthedocs.io/en/latest/) with interesting examples and a detailed package reference. See a more detailed list of features [here](https://updated-spotipy-test.readthedocs.io/en/latest/#features). #### Considering other options None of the original candidates have received commits for the last few months, except Harrison's which after a period of inactivity since August was recently committed to a few times. Unless considerable amounts of code has simply not been pushed, I don't view them as good options. I'd also like to address one particular version, Harrison's [fork](https://github.com/Harrison97/spotipy), since it is the second-most starred option. As I've [stated before](https://github.com/plamere/spotipy/issues/387#issuecomment-538787568), I think the original code is not worth maintaining anymore. And making the same changes I've already made, refactoring and cleaning up documentation seems like a waste of effort. I think my design and features make the package both easier and more flexible to use. So in my opinion it is much better than the original and by extension Harrison's as well, at least if he has no plans of changing it. But I can't speak for everyone. This is no smack-down argument. Whether you like my design is up to you to decide. And he could very well fix the problems I laid out for the original version. I'd love for you to pitch in Harrison! What are you planning to do with the package? Is PyPI a goal for you? #### The human-side of things I've been by far the most active person driving this issue forward and developing a new version. I'm certainly willing to extend that effort to maintaining the package. A number of helpful contributors have already provided great suggestions and bug reports, but I'd like to grow that number and perhaps add another maintainer as well. I dislike the idea of everything depending on one person. #### Time-frame I think after announcing the transfer, one month should go by before releasing the new version. I plan on making a final release of this repository's contents as discussed [here](https://github.com/plamere/spotipy/issues/404#issuecomment-563508181). At least two weeks should go by after that release before releasing the new version.

kerem commented

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

Author

Owner

@AustinPoulson commented on GitHub (Dec 21, 2019):

If you're the new owner on PyPI, then it would make sense to have the repository under your name as well. You seem to have things under control here. You have my vote.

@AustinPoulson commented on GitHub (Dec 21, 2019): If you're the new owner on PyPI, then it would make sense to have the repository under your name as well. You seem to have things under control here. You have my vote.

kerem commented

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

Author

Owner

@thepixelabs commented on GitHub (Dec 21, 2019):

@felix-hilden you wrote a lot about documentation but you need to build it first, having all this online would be much more helpful and collaborative, imo

build docs for example didn't work on my mac.. i resorted to harrison97's repo as that one worked for me right out of the box

@thepixelabs commented on GitHub (Dec 21, 2019): @felix-hilden you wrote a lot about documentation but you need to build it first, having all this online would be much more helpful and collaborative, imo build docs for example didn't work on my mac.. i resorted to harrison97's repo as that one worked for me right out of the box

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 21, 2019):

Oh, please submit an issue about that if you could, @pixelicous with some more information on what you did and what went wrong! I'd hate for it to not work for mac users. The current plan is to use the same RTD project for documentation. That's the reason I haven't updated it yet, but I agree building it yourself is kind of a hassle and having it online would be a quicker way of seeing what I'm talking about. Maybe I should figure out a temporary solution.

@felix-hilden commented on GitHub (Dec 21, 2019): Oh, please submit an issue about that if you could, @pixelicous with some more information on what you did and what went wrong! I'd hate for it to not work for mac users. The current plan is to use the same RTD project for documentation. That's the reason I haven't updated it yet, but I agree building it yourself is kind of a hassle and having it online would be a quicker way of seeing what I'm talking about. Maybe I should figure out a temporary solution.

kerem commented

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

Author

Owner

@thepixelabs commented on GitHub (Dec 21, 2019):

@felix-hilden just solved it, had to install sphinx, sphinx-autodoc-typehints and sphinx_rtd_theme
So docs working and i managed to run some test code as well, it seems like you have the most will to push this forward and making it a robust solution
However I wouldn't rock the boat either way, I would fork the solution and in the end people would use the most updated repo that has the most contributors, features, tests pipeline etc

@thepixelabs commented on GitHub (Dec 21, 2019): @felix-hilden just solved it, had to install sphinx, sphinx-autodoc-typehints and sphinx_rtd_theme So docs working and i managed to run some test code as well, it seems like you have the most will to push this forward and making it a robust solution However I wouldn't rock the boat either way, I would fork the solution and in the end people would use the most updated repo that has the most contributors, features, tests pipeline etc

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 21, 2019):

Good to know then, it can be installed via the optional dependencies as done here (the [dev] part). It will install the packages you mentioned along with a few others needed for development.

@felix-hilden commented on GitHub (Dec 21, 2019): Good to know then, it can be installed via the optional dependencies as done [here](https://github.com/felix-hilden/spotipy#documentation) (the `[dev]` part). It will install the packages you mentioned along with a few others needed for development.

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 21, 2019):

@pixelicous There is now temporary online documentation! I haven't fully figured out the build yet, but at first glance seems that the build was successful. Enjoy :D

@felix-hilden commented on GitHub (Dec 21, 2019): @pixelicous There is now temporary [online documentation](https://updated-spotipy-test.readthedocs.io/en/latest/)! I haven't fully figured out the build yet, but at first glance seems that the build was successful. Enjoy :D

kerem commented

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

Author

Owner

@Harrison97 commented on GitHub (Dec 22, 2019):

Posted this in another thread:

"Hey guys. I am fine with hosting the new main repo for Spotipy. I have been working on it and the goal is to make it fully up to date with their current API and Python3. I currently have it working with Python3 and all tests passing. I am going to keep a lot of the original code. I do want to refactor a lot of it. The testing needs to be consolidated to easily run a full test suite so we can speed up development and make it more easily maintainable. How it is handling the API authentication needs adjustments. And it needs to be fully up to date with everything their API offers.

I will work with the original author and PyPi to get the Spotipy library redirected to the new repo soon.

Thank you guys for y’alls feedback and help. I really appreciate everyone helping get this project back in its feet.

Harrison"

That being said..

I was trying to get a hold of the Spotipy PyPI name earlier in August with no success. Basically my plan was to refactor for easier testing and development. But it seems that you have already done a lot of this. I have looked at your repo a bit and so far from what I do see, it seems really concise and has a lot of refactor work that needed to be done. I would be 100% okay with using your repo as the official Spotipy repo and I would be happy to be one of the reviewers/maintainers. However, I would like to propose that we fix up the old code into a decently working condition with minimal changes to the user implementation(Which I have done, but I would like someone to review). Then publish that version on PyPi as the last 2.X version. This would be so that people that are using the old version could easily upgrade their system to Python3 as well as have access to an updated wrapper that works with their code without having to rewrite everything. Just a small courtesy to help some people out if needed. After that we could start publishing from 3.0 onward and completely discontinue development from the original code completely.

Very good work refactoring and cleaning things up so far. Looking forward to continuing the work on this with you guys! Glad we have found a group of people dedicated to getting this on the move.

Harrison

EDIT: Saw your update plan and it seems like we are on the same page.

@Harrison97 commented on GitHub (Dec 22, 2019): Posted this in another thread: "Hey guys. I am fine with hosting the new main repo for Spotipy. I have been working on it and the goal is to make it fully up to date with their current API and Python3. I currently have it working with Python3 and all tests passing. I am going to keep a lot of the original code. I do want to refactor a lot of it. The testing needs to be consolidated to easily run a full test suite so we can speed up development and make it more easily maintainable. How it is handling the API authentication needs adjustments. And it needs to be fully up to date with everything their API offers. I will work with the original author and PyPi to get the Spotipy library redirected to the new repo soon. Thank you guys for y’alls feedback and help. I really appreciate everyone helping get this project back in its feet. Harrison" That being said.. I was trying to get a hold of the Spotipy PyPI name earlier in August with no success. Basically my plan was to refactor for easier testing and development. But it seems that you have already done a lot of this. I have looked at your repo a bit and so far from what I do see, it seems really concise and has a lot of refactor work that needed to be done. I would be 100% okay with using your repo as the official Spotipy repo and I would be happy to be one of the reviewers/maintainers. However, I would like to propose that we fix up the old code into a decently working condition with minimal changes to the user implementation(Which I have done, but I would like someone to review). Then publish that version on PyPi as the last 2.X version. This would be so that people that are using the old version could easily upgrade their system to Python3 as well as have access to an updated wrapper that works with their code without having to rewrite everything. Just a small courtesy to help some people out if needed. After that we could start publishing from 3.0 onward and completely discontinue development from the original code completely. Very good work refactoring and cleaning things up so far. Looking forward to continuing the work on this with you guys! Glad we have found a group of people dedicated to getting this on the move. Harrison EDIT: Saw your update plan and it seems like we are on the same page.

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 22, 2019):

@Harrison97 my man... I'm so happy for your message and that you are willing to co-operate! Thank you for the kind words. Publishing and update in the 2.X series actually sounds great 👌 I agree, it could help old users a lot. With that in mind, our update plan would perhaps look like this:

2.4.5: Plamere repository contents
2.5.0: Harrison's updates with minimal deprecation notices that can be disabled (don't know how yet, but let's see if that can be arranged, it would be nice to give more time for users to react)
2.6.0: Functionally equivalent, but verbose deprecation notices that can't be disabled

Documentation would of course be versioned too. I'm not sure about the 2.6 release, because the 2.5 deprecations could do the trick. Releasing a dedicated deprecation version in this case seems a bit unnecessary. But let's see and continue the discussion in our repositories.

I'll leave this issue open for people to find and start preparing for the change. I'll do something during the holidays, but come next year, let's start updating! And if there are other repositories announced, we will of course consider them too :D but this looks like the best-case scenario, at least to me. Two most popular versions joining forces.

Have a great end of 2019 everyone!

@felix-hilden commented on GitHub (Dec 22, 2019): @Harrison97 my man... I'm so happy for your message and that you are willing to co-operate! Thank you for the kind words. Publishing and update in the 2.X series actually sounds great 👌 I agree, it could help old users a lot. With that in mind, our update plan would perhaps look like this: - 2.4.5: Plamere repository contents - 2.5.0: Harrison's updates with minimal deprecation notices that can be disabled (don't know how yet, but let's see if that can be arranged, it would be nice to give more time for users to react) - 2.6.0: Functionally equivalent, but verbose deprecation notices that can't be disabled Documentation would of course be versioned too. I'm not sure about the 2.6 release, because the 2.5 deprecations could do the trick. Releasing a dedicated deprecation version in this case seems a bit unnecessary. But let's see and continue the discussion in our repositories. I'll leave this issue open for people to find and start preparing for the change. I'll do something during the holidays, but come next year, let's start updating! And if there are other repositories announced, we will of course consider them too :D but this looks like the best-case scenario, at least to me. Two most popular versions joining forces. Have a great end of 2019 everyone!

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Dec 24, 2019):

Libraries that either don't fork, or don't make any effort to be backward-compatible should not be possible candidates:

I appreciate the effort to push this package forward. I understand the aim is to "help the community". However, breaking compatibility at its root (pip install spotipy) is not helping the community very much.

Taking control of the library to bring fresh updates and fixes is great and you have my full support. Taking control of spotipy to fully replace it is not. This is not what major "versions" are for.

OK, spotipy has been inactive and lacking updates, but things still work well and people use it, is there any reason to deprecate/suppress what still works?

January 2018: https://www.youtube.com/playlist?list=PLqgOPibB_QnzzcaOFYmY2cQjs35y0is9N
October 2019: https://medium.com/@maxtingle/getting-started-with-spotifys-api-spotipy-197c3dc6353b
December 2019: https://dev.to/helloiamarra/how-to-play-spotify-songs-and-show-the-album-art-using-spotipy-library-and-python-5eki
27 GH search pages updated in the last week: https://github.com/search?l=Python&o=desc&q=spotipy&s=indexed&type=Code (total 7k python code results)
6 GH search pages updated in the last week: https://github.com/search?l=Jupyter+Notebook&o=desc&p=6&q=spotipy&s=indexed&type=Code (1.5k jupyter code results)
341 SO mentions https://stackoverflow.com/search?q=spotipy
14500 google results: https://www.google.com/search?q=%22spotipy%22
some offline/private content
etc.

@stephanebruckert commented on GitHub (Dec 24, 2019): Libraries that either don't fork, or don't make any effort to be backward-compatible should **not** be possible candidates: - https://github.com/felix-hilden/spotipy/issues/98 - [saphyel/spotify-api](https://github.com/Saphyel/spotify-api) I appreciate the effort to push this package forward. I understand the aim is to "help the community". However, breaking compatibility at its root (`pip install spotipy`) is not helping the community very much. Taking control of the library to bring fresh updates and fixes is great and you have my full support. Taking control of spotipy to fully replace it is not. This is not what major "versions" are for. OK, spotipy has been inactive and lacking updates, but things still work well and people use it, is there any reason to deprecate/suppress what still works? - January 2018: https://www.youtube.com/playlist?list=PLqgOPibB_QnzzcaOFYmY2cQjs35y0is9N - October 2019: https://medium.com/@maxtingle/getting-started-with-spotifys-api-spotipy-197c3dc6353b - December 2019: https://dev.to/helloiamarra/how-to-play-spotify-songs-and-show-the-album-art-using-spotipy-library-and-python-5eki - 27 GH search pages updated in the last week: https://github.com/search?l=Python&o=desc&q=spotipy&s=indexed&type=Code (total 7k python code results) - 6 GH search pages updated in the last week: https://github.com/search?l=Jupyter+Notebook&o=desc&p=6&q=spotipy&s=indexed&type=Code (1.5k jupyter code results) - 341 SO mentions https://stackoverflow.com/search?q=spotipy - 14500 google results: https://www.google.com/search?q=%22spotipy%22 - some offline/private content - etc.

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 26, 2019):

@stephanebruckert thank you for raising those concerns, and especially for searching for such a list of resources that depend on Spotipy. I think the concerns need to be addressed, though I disagree with you. In particular I don't share your level of concern for backwards-compatibility. Let's try to get at the heart of why we disagree.

Not a fork <=> not a candidate

You say that libraries that either don't fork or don't make any effort to be backwards-compatible should not be possible candidates. Let's tackle that. Bear with me as I state the obvious while addressing your premises.

Non-forks are backwards-incompatible
Disproving this is trivial. One can duplicate the contents of a repository and upload it, making it fully backwards-compatible but also not a fork.
Forks are backwards-compatible
Similar reasoning can be applied here. Any author that forks a repository may overwrite its contents with a single commit, making the fork completely backwards-incompatible.
Backwards-incompatible versions should not be candidates
Now this I agree with, to a degree. For example a library like PyFy should not be chosen as the successor of Spotipy. It is a separate package altogether. Not to mention any package that has nothing to do with Spotify. But this is not the case for all libraries that are strictly backwards-incompatible.

So I think we might agree for now that it is the degree to which the library is backwards-incompatible that should decide whether it is a good candidate or not, among other merits.

Breaking backwards-compatibility is bad

This comes in many forms in your comment: it is bad for the community, you do not support fully replacing a library, and major version numbers are not for denoting complete replacements of a library. Again, I think all of us agree that fully replacing the library is no good. So I think you want to mean that "breaking backwards-compatibility is inherently bad" and that "major versions are not for making backwards-incompatible changes". This I can disagree with.

Two huge examples of successfully breaking backwards-compatibility came to mind. Firstly, the recent release of Tensorflow 2. For those who aren't familiar with it, it's one of the most popular GPU computing / machine learning frameworks, mainly for Python. With 2.0 they made significant changes to their public API and overhauled the way the whole library works by default, changing it from an unintuitive but expert-friendly model to a more easy-to-understand one. And thank God they did! It's a major improvement. Secondly, the release of Python 3. It was, and still is a bit of a mess with the default on many systems being 2.7, but boy do we have the better version now. I would argue that in both cases making backwards-incompatible changes has been a benefit for the community as well.

I'd like to introduce you to semantic versioning, or SemVer. It declares that parts of a version number should have very specific meaning. Major versions are precisely for making incompatible API changes. Preventing developers from introducing backwards-incompatible changes seems crippling. Imagine if we were coding in the closely-related language Mamba, just because some core Python devs didn't want to release Python 3!

We should aim for backwards-compatibility! I'm all for it. But I'm not afraid to make improvements where they are needed.

Backwards-compatibility of my version

I will analyse the entirety of both Plamere's Spotipy and mine to produce a complete compatibility report, motivation for refactoring and upgrade guide. ~~It will take some work, but I'll post it here soon.~~ It is available below. I recognise it is too easy for me to say my version is not that incompatible, because I already know it. So providing this document should help. Maybe, if someone that has already used my version could chime in, how do you see it?

Is there a reason to replace/deprecate working functionality?

Good question! I'll try to answer this in my motivations for refactoring the library. But to paraphrase, in addition to many endpoints needing an update due to changes in the Web API, the naming of client endpoints is inconsistent. There is duplicate functionality in the oauth2 module, providing two methods of authentication in the client is unnecessary, and restricting the available keywords to requests is an arbitrary decision. These are some of the reasons to improve the package for future use.

Let me know what you all think. As I said, this is an important thing to consider. And having an upgrade guide is immensely valuable. Thank you, Stephane.

@felix-hilden commented on GitHub (Dec 26, 2019): @stephanebruckert thank you for raising those concerns, and especially for searching for such a list of resources that depend on Spotipy. I think the concerns need to be addressed, though I disagree with you. In particular I don't share your level of concern for backwards-compatibility. Let's try to get at the heart of why we disagree. #### Not a fork <=> not a candidate You say that libraries that *either* don't fork or don't make any effort to be backwards-compatible should not be possible candidates. Let's tackle that. Bear with me as I state the obvious while addressing your premises. 1. Non-forks are backwards-incompatible Disproving this is trivial. One can duplicate the contents of a repository and upload it, making it fully backwards-compatible but also not a fork. 2. Forks are backwards-compatible Similar reasoning can be applied here. Any author that forks a repository may overwrite its contents with a single commit, making the fork completely backwards-incompatible. 3. Backwards-incompatible versions should not be candidates Now this I agree with, to a degree. For example a library like [PyFy](https://github.com/omarryhan/pyfy) should not be chosen as the successor of Spotipy. It is a separate package altogether. Not to mention any package that has nothing to do with Spotify. But this is not the case for all libraries that are strictly backwards-incompatible. So I think we might agree for now that it is the degree to which the library is backwards-incompatible that should decide whether it is a good candidate or not, among other merits. #### Breaking backwards-compatibility is bad This comes in many forms in your comment: it is bad for the community, you do not support fully replacing a library, and major version numbers are not for denoting complete replacements of a library. Again, I think all of us agree that fully replacing the library is no good. So I think you want to mean that "breaking backwards-compatibility is inherently bad" and that "major versions are not for making backwards-incompatible changes". This I can disagree with. Two huge examples of successfully breaking backwards-compatibility came to mind. Firstly, the recent release of **Tensorflow 2**. For those who aren't familiar with it, it's one of the most popular GPU computing / machine learning frameworks, mainly for Python. With 2.0 they made significant changes to their public API and overhauled the way the whole library works by default, changing it from an unintuitive but expert-friendly model to a more easy-to-understand one. And thank God they did! It's a major improvement. Secondly, the release of **Python 3**. It was, and still is a bit of a mess with the default on many systems being 2.7, but boy do we have the better version now. I would argue that in both cases making backwards-incompatible changes has been a benefit for the community as well. I'd like to introduce you to semantic versioning, or [SemVer](https://semver.org/). It declares that parts of a version number should have very specific meaning. Major versions are precisely for making incompatible API changes. Preventing developers from introducing backwards-incompatible changes seems crippling. Imagine if we were coding in the closely-related language *Mamba*, just because some core Python devs didn't want to release Python 3! We should aim for backwards-compatibility! I'm all for it. But I'm not afraid to make improvements where they are needed. #### Backwards-compatibility of my version I will analyse the entirety of both Plamere's Spotipy and mine to produce a complete compatibility report, motivation for refactoring and upgrade guide. <strike>It will take some work, but I'll post it here soon.</strike> It is available below. I recognise it is too easy for me to say my version is not that incompatible, because I already know it. So providing this document should help. Maybe, if someone that has already used my version could chime in, how do you see it? #### Is there a reason to replace/deprecate working functionality? Good question! I'll try to answer this in my motivations for refactoring the library. But to paraphrase, in addition to many endpoints needing an update due to changes in the Web API, the naming of client endpoints is inconsistent. There is duplicate functionality in the `oauth2` module, providing two methods of authentication in the client is unnecessary, and restricting the available keywords to `requests` is an arbitrary decision. These are some of the reasons to improve the package for future use. Let me know what you all think. As I said, this is an important thing to consider. And having an upgrade guide is immensely valuable. Thank you, Stephane.

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 27, 2019):

Here's the document on backwards-compatibility, reasons for refactoring and upgrade guide!

@felix-hilden commented on GitHub (Dec 27, 2019): [Here](https://gist.github.com/felix-hilden/bce2c6a7f460eaa6ddd5e39aa9d2d028)'s the document on backwards-compatibility, reasons for refactoring and upgrade guide!

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Dec 28, 2019):

@felix-hilden, thanks for a scrupulous answer, but you've been missing out on the context a few times, making it a bit of a deaf dialogue.

You say that libraries that either don't fork or don't make any effort to be backwards-compatible should not be possible candidates. Let's tackle that. Bear with me as I state the obvious while addressing your premises.

Non-forks are backwards-incompatible

Forks are backwards-compatible

You've omitted the context of the sentence and you are assuming that I used an exclusive OR, which is not the case. Therefore "Non-forks are backwards-incompatible" and "Forks are backwards-compatible" were never meant.

So I think you want to mean that "major versions are not for making backwards-incompatible changes". This I can disagree with.

Again this is not what I meant. The quotes around "versions" were meant to emphasise the fact that your codebase is not sourced from the original codebase, therefore it's not a version of it. It is clear you got inspiration from it but you haven't done any work that helps current spotipy users. Tensorflow2 and python3 were both sourced from their original codebases, bringing both backward compatible and incompatible changes, as well as fixes to the previous versions. AFAIK your repo doesn't bring or fix anything without breaking everything else first. A simple example is me trying to use the thumbnail endpoint.

Here's the document on backwards-compatibility, reasons for refactoring and upgrade guide!

Cool, this helps moving from spotipy to your library. But it doesn't specifically solve any of spotipy's current issues:

last version and doc were not published,
bunch of PRs waiting to be merged,
issues cannot be resolved, also making the repo look disorganised.

Let's not lose focus on the context. To avoid burning bridges I suggest to start from the problem, not from the solution. Ideally @plamere would invite motivated contributors to this repo. In that case, this discussion would not even need to take place. If that is not possible, for a new home my vote goes to the most active fork Harrison97/spotipy, for these obvious reasons:

refer to existing issues and use existing pull request contents,
bring conflict-free updates to 494 forks,
if the @plamere repo can come to life again, merge everything back into it from @Harrison97, literally fixing all problems in one go.

Note that issues, links, line numbers, codebases are all history that is worth keeping track of, even in the event of a move from one major version to another.

In the meantime, https://github.com/felix-hilden/spotipy and others are free to thrive. They don't depend on the issues in this repo anyway.

@stephanebruckert commented on GitHub (Dec 28, 2019): @felix-hilden, thanks for a scrupulous answer, but you've been missing out on the context a few times, making it a bit of a deaf dialogue. > You say that libraries that *either* don't fork or don't make any effort to be backwards-compatible should not be possible candidates. Let's tackle that. Bear with me as I state the obvious while addressing your premises. > - Non-forks are backwards-incompatible > - Forks are backwards-compatible You've omitted the context of the sentence and you are assuming that I used an exclusive OR, which [is not the case](https://math.stackexchange.com/questions/2130327/does-either-make-an-exclusive-or). Therefore "Non-forks are backwards-incompatible" and "Forks are backwards-compatible" were never meant. > So I think you want to mean that "major versions are not for making backwards-incompatible changes". This I can disagree with. Again this is not what I meant. The quotes around "versions" were meant to emphasise the fact that your codebase is not sourced from the original codebase, therefore it's not a version of it. It is clear you got inspiration from it but you haven't done any work that helps current spotipy users. Tensorflow2 and python3 were both sourced from their original codebases, bringing both backward compatible and incompatible changes, as well as fixes to the previous versions. AFAIK your repo doesn't bring or fix anything without breaking everything else first. A simple example is me [trying to use the thumbnail endpoint](https://github.com/felix-hilden/spotipy/issues/98). > [Here](https://gist.github.com/felix-hilden/bce2c6a7f460eaa6ddd5e39aa9d2d028)'s the document on backwards-compatibility, reasons for refactoring and upgrade guide! Cool, this helps moving from spotipy to your library. But it doesn't specifically solve any of spotipy's current issues: - last version and doc were not published, - bunch of PRs waiting to be merged, - issues cannot be resolved, also making the repo look disorganised. Let's not lose focus on the context. To avoid burning bridges I suggest to start from the problem, not from the solution. Ideally @plamere would invite motivated contributors to this repo. In that case, this discussion would not even need to take place. If that is not possible, for a new home my vote goes to the most active fork [Harrison97/spotipy](https://github.com/Harrison97/spotipy), for these obvious reasons: - refer to existing issues and use existing pull request contents, - bring conflict-free updates to [494 forks](https://github.com/plamere/spotipy/network/members), - if the @plamere repo can come to life again, merge everything back into it from @Harrison97, literally fixing all problems in one go. Note that issues, links, line numbers, codebases are all history that is worth keeping track of, even in the event of a move from one major version to another. ------- In the meantime, https://github.com/felix-hilden/spotipy and others are free to thrive. They don't depend on the issues in this repo anyway.

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 28, 2019):

Thanks again for the answer and clarifying what you ment @stephanebruckert! I understand your view a lot better now. And I get a chance of really think things through. Opposition is a friend to me.

I did not mean to argue against an exclusive or, that was bad use of cursive on my part. I tried to emphasise the fact that for you it seemed enough that the repository was not a fork for it to not be considered. To me that's not a very good argument. Rather the degree and type of backwards-incompatibility should be the factor to consider.

When it comes to me doing no work for the current Spotipy... Have you noticed, who's always missing from the conversation? Plamere. If it wasn't obvious that he has no interest in anything going on from the PyPI transfer issue, it is 100 % clear now, as even you have pinged him on Twitter, multiple times on GitHub and all these issues referencing themselves have been raised. None of us has done any work for the current Spotipy users, let that be clear. Some have provided alternatives, like Harrison and myself. And I've tried to answer to some of the issues and questions raised here.

My version was sourced from the original repository. Though it is not a fork. One could argue that it should have been to keep the history, but as is suggested here, I decided to create a new project. I did solve the most immediate issues first. There were no special models that were returned from the client. I just cleaned up the functions a bit. Then added the models, different submodules and expanded the whole thing bit by bit to where it is now. Still some work to be done, but far from the starting point. Had I been Plamere, with access to the package, of course different stages would have called for more frequent releases! Behold, I had no access :D But I don't see value in going back to earlier versions just to change less at a time. Choosing Harrison's fork and little by little bringing in changes that I've made seems, as I said above, unnecessary.

Now what was this thumbnail issue you keep referencing? In Plamere's version there is no way of uploading the thumbnail! So what do you mean? Last time I asked, you didn't answer. Please? If you mean that the endpoint should first be brought to the old version before making it return dataclass models, that's.. ok, I guess. If Harrison has introduced such a fix, great! But surely a backwards-incompatible release is allowed to introduce new features as well :D Actually, I haven't reviewed his changes yet, but if he would bring in the Playlist API changes, added market parameters and change defaults to reflect the Web API, most of the changes left in the client would be renaming. But just by looking at the upgrade document, one can conclude that my package is a version of Plamere's.

Now that I have the projects under my name, we intend to publish the final versions of the package and documentation, as laid out above, don't worry. Then publish changes incorporated by Harrison. This should be the compatible update you are looking for. But we have no control over what happens in this repository. So, as unsatisfying as it is, it will stay disorganised.

Now would be a very good time for others to express their opinions about this as well. Lots of angles lead to better solutions. Cheers!

@felix-hilden commented on GitHub (Dec 28, 2019): Thanks again for the answer and clarifying what you ment @stephanebruckert! I understand your view a lot better now. And I get a chance of really think things through. Opposition is a friend to me. I did not mean to argue against an exclusive or, that was bad use of cursive on my part. I tried to emphasise the fact that for you it seemed enough that the repository was not a fork for it to not be considered. To me that's not a very good argument. Rather the degree and type of backwards-incompatibility should be the factor to consider. When it comes to me doing no work for the current Spotipy... Have you noticed, who's always missing from the conversation? Plamere. If it wasn't obvious that he has no interest in anything going on from the PyPI transfer issue, it is 100 % clear now, as even you have pinged him on Twitter, multiple times on GitHub and all these issues referencing themselves have been raised. None of us has done any work for the current Spotipy users, let that be clear. Some have provided alternatives, like Harrison and myself. And I've tried to answer to some of the issues and questions raised here. My version was sourced from the original repository. Though it is not a fork. One could argue that it should have been to keep the history, but as is suggested [here](https://opensource.stackexchange.com/a/1937/15775), I decided to create a new project. I did solve the most immediate issues first. There were no special models that were returned from the client. I just cleaned up the functions a bit. Then added the models, different submodules and expanded the whole thing bit by bit to where it is now. Still some work to be done, but far from the starting point. Had I been Plamere, with access to the package, of course different stages would have called for more frequent releases! Behold, I had no access :D But I don't see value in going back to earlier versions just to change less at a time. Choosing Harrison's fork and little by little bringing in changes that I've made seems, as I said above, unnecessary. Now what was this thumbnail issue you keep referencing? In Plamere's version there is no way of uploading the thumbnail! So what do you mean? Last time I asked, you didn't answer. Please? If you mean that the endpoint should first be brought to the old version before making it return dataclass models, that's.. ok, I guess. If Harrison has introduced such a fix, great! But surely a backwards-incompatible release is allowed to introduce new features as well :D Actually, I haven't reviewed his changes yet, but if he would bring in the Playlist API changes, added market parameters and change defaults to reflect the Web API, most of the changes left in the client would be renaming. But just by looking at the upgrade document, one can conclude that my package is a version of Plamere's. Now that I have the projects under my name, we intend to publish the final versions of the package and documentation, as laid out above, don't worry. Then publish changes incorporated by Harrison. This should be the compatible update you are looking for. But we have no control over what happens in this repository. So, as unsatisfying as it is, it will stay disorganised. Now would be a very good time for others to express their opinions about this as well. Lots of angles lead to better solutions. Cheers!

kerem commented

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

Author

Owner

@Harrison97 commented on GitHub (Dec 28, 2019):

I completely agree with stephanebruckert here. That was my only issue with going with your repo. Typically when maintaining a piece of software, especially open source we do want to keep the history and commit history in tact and maintain full backwards compatibility. And we want to make smaller commits, if possible, so that in the event issues do arise, we have that history. The main issues I see with going with your current iteration is that it doesn’t follow a lot of this. And while it may work well and be convenient for you, it’s not so convenient for other contributors and maintainers that want to get involved. Or is it for the past contributor and maintainer. And I believe that is something that we should take into great consideration when continuing work from this project.

As of now I am holding off on making any major updates to my master branch as it is just the next iteration of a working spotipy; fixing bugs and updating a few things, documentation does need to be updated. I’m trying to not stray from original code too much until we solidify a plan that everyone is on board with. I’m not in the business of going down a path that is not going to be adopted by the community and wasting time and work. But I will say that I can start another branch and we/I can start making PRS to it based on your current refactoring to see how well it integrates. I do agree that you have taken a massive step forward with this package but I do agree that we should be continuing with smaller increments to ensure that we still abide by quality and well respected software design principles.

I very much respect your work and dedication to getting this up and running Felix! But I do believe that there are some things about the future maintenance and development that we need to be taking seriously to ensure that we set ourselves up for success. Spotify is going to be around for a long time, there is no doubt. This package has potential to be a widely used and the main source for people to go to interact with their API. In 5 years the maintainers might not be you and I. We need to set these people up for success and think more long term.

@Harrison97 commented on GitHub (Dec 28, 2019): I completely agree with stephanebruckert here. That was my only issue with going with your repo. Typically when maintaining a piece of software, especially open source we do want to keep the history and commit history in tact and maintain full backwards compatibility. And we want to make smaller commits, if possible, so that in the event issues do arise, we have that history. The main issues I see with going with your current iteration is that it doesn’t follow a lot of this. And while it may work well and be convenient for you, it’s not so convenient for other contributors and maintainers that want to get involved. Or is it for the past contributor and maintainer. And I believe that is something that we should take into great consideration when continuing work from this project. As of now I am holding off on making any major updates to my master branch as it is just the next iteration of a working spotipy; fixing bugs and updating a few things, documentation does need to be updated. I’m trying to not stray from original code too much until we solidify a plan that everyone is on board with. I’m not in the business of going down a path that is not going to be adopted by the community and wasting time and work. But I will say that I can start another branch and we/I can start making PRS to it based on your current refactoring to see how well it integrates. I do agree that you have taken a massive step forward with this package but I do agree that we should be continuing with smaller increments to ensure that we still abide by quality and well respected software design principles. I very much respect your work and dedication to getting this up and running Felix! But I do believe that there are some things about the future maintenance and development that we need to be taking seriously to ensure that we set ourselves up for success. Spotify is going to be around for a long time, there is no doubt. This package has potential to be a widely used and the main source for people to go to interact with their API. In 5 years the maintainers might not be you and I. We need to set these people up for success and think more long term.

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 29, 2019):

You have a good point about keeping history, @Harrison97. Forks are in a bit of a disadvantage on GitHub. For example code search is not available! Unless the fork has more stars than the original repo. Security vulnerability detection neither. I haven't found a complete list. So it's sub-optimal.

However, there is a way of bringing Plamere's commit history in via git replace. It achieves a few important things.

Plamere's (or Harrison's) full and unaffected commit history available in the same repository, not dependent on other repositories
Does not affect my commit history, meaning all existing references in pull requests and issues, as well as contributions are preserved

Some notes:

The replacement does not show in GitHub's UI for some reason. For this I propose an entry in our readme with information and instructions.
The replacement is not downloaded by default. This I actually consider a positive thing, because it speeds up cloning. Normally contributors should be interested in only the most recent commits.
I intend to rebase my changes to have a fuller initial commit instead of ~5 small configuration steps. This way the replacement should be quite clear. Rebasing makes my git history lose its branches. But all the relevant commits are preserved, so it's a price I'm willing to pay.

An example repository can be found here. Optimally, the commits would be listed on the UI by default, or at least the parent of my initial commit would be nonempty, but that's an issue with GitHub. By cloning and fetching replacements (git fetch origin '+refs/replace/*:refs/replace/*'), one can see the full commit log via git log --oneline, reaching all the way to Plamere's initial commit. Before 3.0 I would push this kind of version with the appropriate parent to my repository.

My commits have been very reasonably sized. But there are 300 of them! The first ones simply split the client into different files and then combined the classes in OAuth2. Incremental improvements from the beginning, as per any software maintenance best practices.

Harrison, do you really mean "we do want to -- maintain full backwards compatibility"? I sincerely hope, and do believe, that you do not mean that we should never break backwards compatibility. As we've discussed extensively compatibility is not something to break on a whim. But to me, not something to hold on to madly either. Though I agree that following SemVer, we should refrain from making incompatible changes before version 3. What would you propose that we include in those changes?

@felix-hilden commented on GitHub (Dec 29, 2019): You have a good point about keeping history, @Harrison97. Forks are in a bit of a disadvantage on GitHub. For example code search is not available! Unless the fork has more stars than the original repo. Security vulnerability detection neither. I haven't found a complete list. So it's sub-optimal. However, there is a way of bringing Plamere's commit history in via `git replace`. It achieves a few important things. - Plamere's (or Harrison's) full and unaffected commit history available in the same repository, not dependent on other repositories - Does not affect my commit history, meaning all existing references in pull requests and issues, as well as contributions are preserved Some notes: - The replacement does not show in GitHub's UI for some reason. For this I propose an entry in our readme with information and instructions. - The replacement is not downloaded by default. This I actually consider a positive thing, because it speeds up cloning. Normally contributors should be interested in only the most recent commits. - I intend to rebase my changes to have a fuller initial commit instead of ~5 small configuration steps. This way the replacement should be quite clear. Rebasing makes my git history lose its branches. But all the relevant commits are preserved, so it's a price I'm willing to pay. An example repository can be found [here](https://github.com/felix-hilden/spotipy-amalgam). Optimally, the commits would be listed on the UI by default, or at least the parent of my initial commit would be nonempty, but that's an issue with GitHub. By cloning and fetching replacements (`git fetch origin '+refs/replace/*:refs/replace/*'`), one can see the full commit log via `git log --oneline`, reaching all the way to Plamere's initial commit. Before 3.0 I would push this kind of version with the appropriate parent to my repository. My commits have been very reasonably sized. But there are 300 of them! The first ones simply split the client into different files and then combined the classes in `OAuth2`. Incremental improvements from the beginning, as per any software maintenance best practices. Harrison, do you really mean "we do want to -- maintain full backwards compatibility"? I sincerely hope, and do believe, that you do not mean that we should never break backwards compatibility. As we've discussed extensively compatibility is not something to break on a whim. But to me, not something to hold on to madly either. Though I agree that following SemVer, we should refrain from making incompatible changes before version 3. What would you propose that we include in those changes?

kerem commented

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

Author

Owner

@plamere commented on GitHub (Dec 30, 2019):

hey all - thanks much for working on this. Apologies for being a neglectful owner. I'm happy to see you all working hard to get the package under control. I've added you 3 as collaborators to the plamere/spotipy repos. Let me know if there's anything else I can do to help.

@plamere commented on GitHub (Dec 30, 2019): hey all - thanks much for working on this. Apologies for being a neglectful owner. I'm happy to see you all working hard to get the package under control. I've added you 3 as collaborators to the plamere/spotipy repos. Let me know if there's anything else I can do to help.

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Dec 30, 2019):

Hi @plamere, many thanks! I'm happy to dedicate some time for it and I'm sure we will get the library back on track.

I was thinking that a Gitter room for chatty and general discussions would be great, but https://gitter.im/home#createcommunity says that "spotipy" is already taken. By any chance does one of us already own it?

@stephanebruckert commented on GitHub (Dec 30, 2019): Hi @plamere, many thanks! I'm happy to dedicate some time for it and I'm sure we will get the library back on track. I was thinking that a Gitter room for chatty and general discussions would be great, but https://gitter.im/home#createcommunity says that "spotipy" is already taken. By any chance does one of us already own it?

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 30, 2019):

A plot twist indeed.

First of all, thank you Paul for creating this package. It's too bad that something drew you away from developing it further. I was quite frustrated with the silence, but I don't want to hold grudges. It's good that you are here.

Development could now continue in this repository. I have some questions that I'd like to be answered.

Are you, @stephanebruckert willing to actively contribute to this library? You have previously expressed no such will, but since you were invited as a contributor, I'd like to ask anyway. Aaand you posted a comment just now saying that you can dedicate some time. So that's a yes? And @plamere as well: do you plan on contributing or are you here to simply pass on the torch?
If there are multiple contributors, should the repository be under an organisation instead? I'm sure this one could be transferred under one, so no need to make new repositories. This would allow for more careful management of access particularly in the event that Paul isn't planning to be more active.
Do you share my vision of the Spotipy library? Regardless of the amount of work left to be done or length of the time-frame. If not, what do you see?

A chat room? Sure, why not.

@felix-hilden commented on GitHub (Dec 30, 2019): A plot twist indeed. First of all, thank you Paul for creating this package. It's too bad that something drew you away from developing it further. I was quite frustrated with the silence, but I don't want to hold grudges. It's good that you are here. Development could now continue in this repository. I have some questions that I'd like to be answered. - Are you, @stephanebruckert willing to actively contribute to this library? You have previously expressed no such will, but since you were invited as a contributor, I'd like to ask anyway. Aaand you posted a comment just now saying that you can dedicate *some* time. So that's a yes? And @plamere as well: do you plan on contributing or are you here to simply pass on the torch? - If there are multiple contributors, should the repository be under an organisation instead? I'm sure this one could be transferred under one, so no need to make new repositories. This would allow for more careful management of access particularly in the event that Paul isn't planning to be more active. - Do you share my vision of the Spotipy library? Regardless of the amount of work left to be done or length of the time-frame. If not, what do you see? A chat room? Sure, why not.

kerem commented

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

Author

Owner

@plamere commented on GitHub (Dec 30, 2019):

Hey all:

I'm very interested in the future of this package. I have dozens and dozens of apps that use spotipy and I intend to write more. As the delinquent parent of the package, my opinion on its future is probably not too important, but I would at least hope that in the future if I do a "pip install spotipy" that all my programs won't break. Of course there will be changes to fix bugs, make things consistent, and to deal with changes in the Spotify Web API - but I would not be happy to have to revisit all of my spotipy calls to adapt to a new response format. I suspect that the same is true for other users of the package.

It seems to me that a spotipy update that requires wholesale changes to working code should be packaged under a different name. That way, those that are using the old style don't have to change, while those that want the new shiny goodness of a response model can get it by installing spotipy2 (or whatever it is ultimately called).

P

@plamere commented on GitHub (Dec 30, 2019): Hey all: I'm very interested in the future of this package. I have dozens and dozens of apps that use spotipy and I intend to write more. As the delinquent parent of the package, my opinion on its future is probably not too important, but I would at least hope that in the future if I do a "pip install spotipy" that all my programs won't break. Of course there will be changes to fix bugs, make things consistent, and to deal with changes in the Spotify Web API - but I would not be happy to have to revisit all of my spotipy calls to adapt to a new response format. I suspect that the same is true for other users of the package. It seems to me that a spotipy update that requires wholesale changes to working code should be packaged under a different name. That way, those that are using the old style don't have to change, while those that want the new shiny goodness of a response model can get it by installing spotipy2 (or whatever it is ultimately called). P

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Dec 31, 2019):

Fair enough, it seems that if active development is continued here according to this conservative vision, my version could be better off being a separate package. You've seen my arguments for the progressive vision many times, I'll spare you the read.

I'd like Harrison to pitch in before making any plans. Whaddaya reckon?

@felix-hilden commented on GitHub (Dec 31, 2019): Fair enough, it seems that if active development is continued here according to this conservative vision, my version could be better off being a separate package. You've seen my arguments for the progressive vision many times, I'll spare you the read. I'd like Harrison to pitch in before making any plans. Whaddaya reckon?

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 1, 2020):

Yes @Harrison97 please let us know. Does it look safe to you that we pull everything from https://github.com/Harrison97/spotipy-plamere/ back into this repo and then create 2.5.0? Looks fine by me, I've ran the tests on my side and they all pass.

Just before doing that and as suggested earlier, @felix-hilden would you assist with creating 2.4.5 on pip for the repo in its current state?

I've slowly started to close stale issues. I realised that we will be able to close ~10% more of them just by publishing on PyPi.

@stephanebruckert commented on GitHub (Jan 1, 2020): Yes @Harrison97 please let us know. Does it look safe to you that we pull everything from https://github.com/Harrison97/spotipy-plamere/ back into this repo and then create 2.5.0? Looks fine by me, I've ran the tests on my side and they all pass. Just before doing that and as suggested earlier, @felix-hilden would you assist with creating 2.4.5 on pip for the repo in its current state? I've slowly started to close stale issues. I realised that we will be able to close ~10% more of them just by publishing on PyPi.

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 4, 2020):

Hi @felix-hilden

To answer your previous question, yes I've got time to maintain spotipy. This package has been very useful to me in the past and today I'm happy to give back. Also we now have everything in our power to do things the right way.

My direct question to you is, do you plan to work on spotipy in any way? You are currently the owner of it on PyPI and Read The Docs but you don't seem to have accepted the invitation to join this repo as a collaborator.

Depending on your status, we might need to request transfers of ownership again. I guess the only way is to request the admins to do that since the UIs don't seem to allow it. In that case please let me know if we can aim for a smooth transition by agreeing on the situation now, the main goal being to not disturb the PyPi + RTD admins for too long.

Cheers,
And wishing you and everyone all the best for 2020

@stephanebruckert commented on GitHub (Jan 4, 2020): Hi @felix-hilden To answer your previous question, yes I've got time to maintain spotipy. This package has been very useful to me in the past and today I'm happy to give back. Also we now have everything in our power to do things the right way. My direct question to you is, do you plan to work on spotipy in any way? You are currently the owner of it on [PyPI](https://github.com/pypa/pypi-support/issues/28) and [Read The Docs](https://github.com/readthedocs/readthedocs.org/issues/6335) but you don't seem to have accepted the invitation to join this repo as a collaborator. Depending on your status, we might need to request transfers of ownership again. I guess the only way is to request the admins to do that since the UIs don't seem to allow it. In that case please let me know if we can aim for a smooth transition by agreeing on the situation now, the main goal being to not disturb the PyPi + RTD admins for too long. Cheers, And wishing you and everyone all the best for 2020

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Jan 4, 2020):

Good to hear! Yes, I've deliberately put off accepting the invitation. As I said, I'd like to start making plans only after hearing Harrison's take.

As I've stated previously on numerous occasions, I would have less motivation to maintain the original code. I've essentially addessed everything I can possibly imagine in my own version. And much less now that you and Paul have both made it clear that you don't share my vision of Spotipy.

Transfers can be made from the UI, both on RTD and PyPI. Lot's of these kinds of issues have been resolved that way. No need to bother admins, should it come to that. PyPI at least allows one to add collaborators, I have not tested kicking myself out quite yet, for obvious reasons.

@Harrison97, wherefore art thou?

@felix-hilden commented on GitHub (Jan 4, 2020): Good to hear! Yes, I've deliberately put off accepting the invitation. As I said, I'd like to start making plans only after hearing Harrison's take. As I've stated previously on numerous occasions, I would have less motivation to maintain the original code. I've essentially addessed everything I can possibly imagine in my own version. And much less now that you and Paul have both made it clear that you don't share my vision of Spotipy. Transfers can be made from the UI, both on RTD and PyPI. Lot's of these kinds of issues have been resolved that way. No need to bother admins, should it come to that. PyPI at least allows one to add collaborators, I have not tested kicking myself out quite yet, for obvious reasons. @Harrison97, wherefore art thou?

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 4, 2020):

If possible for PyPi and RTD I would respect the same structure as on Github:

@plamere (owner)
- @Harrison97 (maintainer)
- myself (maintainer)

All good. Let's wait for Harrison a bit more

@stephanebruckert commented on GitHub (Jan 4, 2020): If possible for PyPi and RTD I would respect the same structure as on Github: - @plamere (owner) - @Harrison97 (maintainer) - myself (maintainer) All good. Let's wait for Harrison a bit more

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Jan 4, 2020):

You can just remove the thing man, no reason to keep the misunderstanding there. Although I can appreciate and enjoy a good (attempted) whooping 😄

I would second your structure if Plamere had plans to continue the maintenance himself. I've already suggested using an organisation in GitHub to make it a non-issue to handle ownership. But if you all agree that it should be kept this way, I won't stand against you.

@felix-hilden commented on GitHub (Jan 4, 2020): You can just remove the thing man, no reason to keep the misunderstanding there. Although I can appreciate and enjoy a good (attempted) whooping 😄 I would second your structure if Plamere had plans to continue the maintenance himself. I've already suggested using an organisation in GitHub to make it a non-issue to handle ownership. But if you all agree that it should be kept this way, I won't stand against you.

kerem commented

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

Author

Owner

@ritiek commented on GitHub (Jan 8, 2020):

@felix-hilden Could we please publish the current master branch on PyPI (as v2.5.0?) for now? The latest spotipy release was published on Jan 5, 2017. The current master branch in this repo consist commits until Oct 1, 2017. I think it should be a good idea to incorporate changes from current master to a PyPI release until the next big move is made.

EDIT: Also see #337.

@ritiek commented on GitHub (Jan 8, 2020): @felix-hilden Could we please publish the current master branch on PyPI (as v2.5.0?) for now? The latest spotipy release was published on [Jan 5, 2017](https://pypi.org/project/spotipy/#history). The current master branch in this repo consist commits until [Oct 1, 2017](https://github.com/plamere/spotipy/commits/master). I think it should be a good idea to incorporate changes from current master to a PyPI release until the next big move is made. **EDIT:** Also see #337.

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 8, 2020):

Yes @ritiek let's do it. Is that fine @felix-hilden?

When possible please add me as a maintainer on PyPi (username stephanebruckert) and transfer ownership to @plamere, who will then be able to invite Harisson97 if needed.

About RTD, are you able to add maintainers and do transfers? If yes, please do the same as for PyPi. If not, I suppose you can transfer the repo to me, because I'm available now. My username is stephanebruckert.

Thanks a lot

@stephanebruckert commented on GitHub (Jan 8, 2020): Yes @ritiek let's do it. Is that fine @felix-hilden? When possible please add me as a maintainer on PyPi (username stephanebruckert) and transfer ownership to [@plamere](https://pypi.org/user/plamere/), who will then be able to invite Harisson97 if needed. About RTD, are you able to add maintainers and do transfers? If yes, please do the same as for PyPi. If not, I suppose you can transfer the repo to me, because I'm available now. My username is stephanebruckert. Thanks a lot

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Jan 10, 2020):

That would be nice @ritiek.

Forgive me for my continuing lack of trust, but I ask once more. @plamere can you confirm that you are indeed available if changes to maintainers on this repository or the PyPI/RTD projects are needed? If so, I trust you have things under control and will transfer rights on the projects right away. Then you can orchestrate the update as you please.

If not, or we don't get a response soon enough, @stephanebruckert please update the new version number in setup and I'll build the package as it is during this weekend. If not updated, I'll set the version to '2.5.0'.

@felix-hilden commented on GitHub (Jan 10, 2020): That would be nice @ritiek. Forgive me for my continuing lack of trust, but I ask once more. @plamere can you confirm that you are indeed available if changes to maintainers on this repository or the PyPI/RTD projects are needed? If so, I trust you have things under control and will transfer rights on the projects right away. Then you can orchestrate the update as you please. If not, or we don't get a response soon enough, @stephanebruckert please update the new version number in [setup](https://github.com/plamere/spotipy/blob/master/setup.py#L5) and I'll build the package as it is during this weekend. If not updated, I'll set the version to `'2.5.0'`.

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 10, 2020):

@plamere please confirm

@stephanebruckert commented on GitHub (Jan 10, 2020): @plamere please confirm

kerem commented

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

Author

Owner

@plamere commented on GitHub (Jan 11, 2020):

confirmed

@plamere commented on GitHub (Jan 11, 2020): confirmed

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 11, 2020):

Please @felix-hilden add me as a maintainer before transferring the repo

@stephanebruckert commented on GitHub (Jan 11, 2020): Please @felix-hilden add me as a maintainer before transferring the repo

kerem commented

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

Author

Owner

@felix-hilden commented on GitHub (Jan 11, 2020):

You are now the maintainers of those projects, with Paul as the PyPI owner. It seems I cannot exit either of them by myself, so feel free to remove me. I have declined the collaboration invitation on GitHub. Best of luck with Spotipy!

@felix-hilden commented on GitHub (Jan 11, 2020): You are now the maintainers of those projects, with Paul as the PyPI owner. It seems I cannot exit either of them by myself, so feel free to remove me. I have declined the collaboration invitation on GitHub. Best of luck with Spotipy!

kerem commented

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

Author

Owner

@stephanebruckert commented on GitHub (Jan 11, 2020):

Perfect, thanks!

@stephanebruckert commented on GitHub (Jan 11, 2020): Perfect, thanks!

kerem referenced this issue

2026-02-28 00:01:58 +03:00

[PR #239] [CLOSED] Fix prompt_for_user_token parameter strings #829

Rows
Columns

[GH-ISSUE #406] Choosing a new home for Spotipy #239

Original issue: Is under development?

The current discussion

spotipy - felix-hilden

Comparison with Plamere

Highlights

Considering other options

The human-side of things

Time-frame

Not a fork <=> not a candidate

Breaking backwards-compatibility is bad

Backwards-compatibility of my version

Is there a reason to replace/deprecate working functionality?