[GH-ISSUE #404] I'm the new maintainer, what should we do? #240

New issue

Closed

opened 2026-02-27 23:21:33 +03:00 by kerem · 14 comments

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

Owner

Copy link

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

Hello! Plamere has been inactive for a long time so Spotipy has been transferred to my name on PyPI and a similar process is ongoing for Read The Docs. Next, we should figure out what to do with the acquired rights.

The situation

Plamere has been inactive since late 2017. The repository contains and the documentation references code that was not released in version 2.4.4, which is the most recent release on PyPI. This led to a lot of confusion for me when I tried out this library and I understand this has been the case for many others as well.

Spotify's Web API has progressed over the years. For example, playlists are no longer accessed via a user (dev news) and new endpoints have been added. The API will continue to evolve.

Spotipy is fairly popular, pulling in up to a thousand downloads a day and gaining popularity over time. This means that lots of new users are affected by the decisions that are made now.

The options

Possible solutions can be divided into two archetypes: conservative and progressive. I'll post them both below so we can discuss them in detail and tweak them if needed.

A number of forked/rewritten projects have emerged. I have also written a version, which was what I referenced during the name transfers, but I'd like to keep the conversation open to other options as well. And I specifically would like to avoid choosing one of the new versions in this issue. If we choose the progressive solution, I'll open another issue for that discussion. That being said, please do dive into the issue and have a look at the proposed alternatives to gain an understanding of what types of solutions could be implemented as part of the progressive plan.

Originally created by @felix-hilden on GitHub (Dec 10, 2019). Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/404 Hello! 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 a similar process is ongoing for [Read The Docs](https://github.com/readthedocs/readthedocs.org/issues/6335). Next, we should figure out what to do with the acquired rights. ### The situation Plamere has been inactive since late 2017. The repository contains and the documentation references code that was not released in version 2.4.4, which is the most recent release on PyPI. This led to a lot of confusion for me when I tried out this library and I understand this has been the case for many others as well. Spotify's Web API has progressed over the years. For example, playlists are no longer accessed via a user ([dev news](https://developer.spotify.com/community/news/2019/01/15/update-changes-to-playlist-uris/)) and new endpoints have been added. The API will continue to evolve. Spotipy is [fairly popular](https://pypistats.org/packages/spotipy), pulling in up to a thousand downloads a day and gaining popularity over time. This means that lots of new users are affected by the decisions that are made now. ### The options Possible solutions can be divided into two archetypes: conservative and progressive. I'll post them both below so we can discuss them in detail and tweak them if needed. A number of forked/rewritten projects [have emerged](https://github.com/plamere/spotipy/issues/387). I have also written a version, which was what I referenced during the name transfers, but I'd like to keep the conversation open to other options as well. And I specifically would like to avoid choosing one of the new versions in this issue. If we choose the progressive solution, I'll open another issue for that discussion. That being said, please do dive into the issue and have a look at the proposed alternatives to gain an understanding of what types of solutions could be implemented as part of the progressive plan.

kerem closed this issue 2026-02-27 23:21:34 +03:00

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

Author

Owner

Copy link

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

Conservative

The conservative solution is the easy, hassle-free way out. In my mind it has three variations.

We do absolutely nothing

'Nuff said.

We publish one more version

Publishing the final contents of this repository on PyPI would bring the documentation in sync with the published version. This version could be 2.4.5 for example.

We notify users about other options

If maintenance is not continued, it could be fair to ease the pain of finding another up-to-date solution. This could be implemented in documentation, warning messages on importing the library or any other method.

In this case, we should publish the repo contents first in my opinion. Then if code needs to be modified, it could be version 2.5.0 for example.

Pros:

• Status quo is preserved. Nothing is required of existing users of the library.
• No confusion with new versions or other resources on the web being out-of-date.

Cons:

• A weak long-term strategy. It will lead to the obsoletion of Spotipy as the Web API evolves.

<!-- gh-comment-id:563508181 --> @felix-hilden commented on GitHub (Dec 10, 2019): ### Conservative The conservative solution is the easy, hassle-free way out. In my mind it has three variations. #### We do absolutely nothing 'Nuff said. #### We publish one more version Publishing the final contents of this repository on PyPI would bring the documentation in sync with the published version. This version could be `2.4.5` for example. #### We notify users about other options If maintenance is not continued, it could be fair to ease the pain of finding another up-to-date solution. This could be implemented in documentation, warning messages on importing the library or any other method. In this case, we should publish the repo contents first in my opinion. Then if code needs to be modified, it could be version `2.5.0` for example. Pros: - Status quo is preserved. Nothing is required of existing users of the library. - No confusion with new versions or other resources on the web being out-of-date. Cons: - A weak long-term strategy. It will lead to the obsoletion of Spotipy as the Web API evolves.

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

Author

Owner

Copy link

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

Progressive

The progressive solution is the slow payoff route. It could build on other steps in the conservative plan but then continue on with maintenance and enhancement of Spotipy. Another repository would be designated as the new home of Spotipy and its contributors would actively release new versions of the package and documentation.

Pros:

• A strong long-term strategy. The library will stay up-to-date with the API and potentially develop in other ways as well.

Cons:

• Status quo disturbed. Publishing new versions could require old users to either require an older version of Spotipy or update their code.
• Potentially backwards-incompatible. As the Web API changes, new versions of the library will need to be published. For example, the playlist changes contain such modifications.
• Confusion when changing the repository. Even if backwards-compatible, users could find the old and still popular repo instead of the new one.

<!-- gh-comment-id:563508531 --> @felix-hilden commented on GitHub (Dec 10, 2019): ### Progressive The progressive solution is the slow payoff route. It could build on other steps in the conservative plan but then continue on with maintenance and enhancement of Spotipy. Another repository would be designated as the new home of Spotipy and its contributors would actively release new versions of the package and documentation. Pros: - A strong long-term strategy. The library will stay up-to-date with the API and potentially develop in other ways as well. Cons: - Status quo disturbed. Publishing new versions could require old users to either require an older version of Spotipy or update their code. - Potentially backwards-incompatible. As the Web API changes, new versions of the library will need to be published. For example, the playlist changes contain such modifications. - Confusion when changing the repository. Even if backwards-compatible, users could find the old and still popular repo instead of the new one.

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

Author

Owner

Copy link

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

My take

I think it is best to think long-term. And publishing further versions of Spotipy is preferrable to developing a new library because Spotipy is already an established package. New users would already have the most recent version instead of having to look for another package, and the necessary changes for old users are reasonable.

<!-- gh-comment-id:563509168 --> @felix-hilden commented on GitHub (Dec 10, 2019): ### My take I think it is best to think long-term. And publishing further versions of Spotipy is preferrable to developing a new library because Spotipy is already an established package. New users would already have the most recent version instead of having to look for another package, and the necessary changes for old users are reasonable.

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

Author

Owner

Copy link

@naringas commented on GitHub (Dec 10, 2019):

Rergardless of what is decided, a 2.4.5 release should happen just to bring the documentation in sync with pypi.

Having read through some of https://github.com/plamere/spotipy/issues/387 it seems that the central question is: which fork to keep as the 'official' version? (i.e. the "spotipy" name in PyPI)

In my opition, and because of what @felix-hilden says in this summary:

As I understand it, the original spotipy package was very much a light-weight wrapper around the API, and Harrison's fork remains faithful to that idea. My rewrite has more structure surrounding the client, for example scope and token objects, response models and extendable request senders.

And thus, I think that https://github.com/Harrison97/spotipy is what should probaby carry on as the 'official' (i.e. in PyPI) spotipy name. (however what is really important is what does @Harrison97 think about his?)

And given as @felix-hilden version is a fuller re-write maybe rename the pacakge as spotipy3 for PyPI? 🤷‍♂️

Personally I just got here (from spotify's developer libraries documentation). And I was able to use pypi's code (this repo version 2.4.4) and it worked in python 3.7 for a very basic oatuh flow and listing a user and their playlitsts.
This to me, is a testament of something done right. All I had to do is change print into function calls in the code example from readthedocs.

<!-- gh-comment-id:564167282 --> @naringas commented on GitHub (Dec 10, 2019): Rergardless of what is decided, a `2.4.5` release should happen just to bring the documentation in sync with pypi. Having read through some of https://github.com/plamere/spotipy/issues/387 it seems that the central question is: **which fork to keep as the 'official' version?** (i.e. the "spotipy" name in PyPI) In my opition, and because of what @felix-hilden [says in this summary](https://github.com/plamere/spotipy/issues/387#issuecomment-538787568): > As I understand it, the original spotipy package was very much a light-weight wrapper around the API, and Harrison's fork remains faithful to that idea. My rewrite has more structure surrounding the client, for example scope and token objects, response models and extendable request senders. And thus, I think that https://github.com/Harrison97/spotipy is what should probaby carry on as the 'official' (i.e. in PyPI) spotipy name. (however what is really important is what does @Harrison97 think about his?) And given as @felix-hilden version is a fuller re-write maybe rename the pacakge as `spotipy3` for PyPI? :man_shrugging: Personally I just got here (from [spotify's developer libraries documentation](https://developer.spotify.com/documentation/web-api/libraries/)). And I was able to use pypi's code (this repo version 2.4.4) and it worked in python 3.7 for a very basic oatuh flow and listing a user and their playlitsts. This to me, is a testament of something done right. All I had to do is change `print` into function calls in the code example from readthedocs.

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

Author

Owner

Copy link

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

Thanks for the input, it's cool that the newest of users also discover this! As I said, I'd like for us just to discuss whether we should continue to actively maintain this code or not. I take it that you are on the progressive side. And I strongly agree that the sync should happen in any case.

<!-- gh-comment-id:564204050 --> @felix-hilden commented on GitHub (Dec 10, 2019): Thanks for the input, it's cool that the newest of users also discover this! As I said, I'd like for us just to discuss whether we should continue to actively maintain this code or not. I take it that you are on the progressive side. And I strongly agree that the sync should happen in any case.

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

Author

Owner

Copy link

@mdrzn commented on GitHub (Dec 13, 2019):

+1 on the progressive, and I just found out today about this repo. Great project.

<!-- gh-comment-id:565585992 --> @mdrzn commented on GitHub (Dec 13, 2019): +1 on the progressive, and I just found out today about this repo. Great project.

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

Author

Owner

Copy link

@SeanKohlbrenner commented on GitHub (Dec 16, 2019):

I agree on the progressive route. I tried to use this project recently and had to find an alternative because of how outdated/broken the documentation was for the current Spotify API. I also agree that Spotipy should evolve alongside the API to continue being useful.

<!-- gh-comment-id:566222613 --> @SeanKohlbrenner commented on GitHub (Dec 16, 2019): I agree on the progressive route. I tried to use this project recently and had to find an alternative because of how outdated/broken the documentation was for the current Spotify API. I also agree that Spotipy should evolve alongside the API to continue being useful.

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

Author

Owner

Copy link

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

Thank you both! With no opposition, it seems that the progressive route is a no-brainer. I'll post the issue to choose a successor to Spotipy soon. Maybe once I acquire the RTD project as well, so we have everything we need. But do still voice your opinion even if you agree with everyone here. It's valuable input!

That's too bad, @SeanKohlbrenner. Hopefully you still want to give the new version a go. These kinds of users are a sad story for the package. Stay tuned.

<!-- gh-comment-id:566442031 --> @felix-hilden commented on GitHub (Dec 17, 2019): Thank you both! With no opposition, it seems that the progressive route is a no-brainer. I'll post the issue to choose a successor to Spotipy soon. Maybe once I acquire the RTD project as well, so we have everything we need. But do still voice your opinion even if you agree with everyone here. It's valuable input! That's too bad, @SeanKohlbrenner. Hopefully you still want to give the new version a go. These kinds of users are a sad story for the package. Stay tuned.

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

Author

Owner

Copy link

@oscarsidebo commented on GitHub (Dec 17, 2019):

• 1 on progressive route 👍

<!-- gh-comment-id:566448751 --> @oscarsidebo commented on GitHub (Dec 17, 2019): + 1 on progressive route 👍

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

Author

Owner

Copy link

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

There's the new issue! Now let's find a new home.

<!-- gh-comment-id:567561727 --> @felix-hilden commented on GitHub (Dec 19, 2019): There's the new issue! Now let's find a new home.

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

Author

Owner

Copy link

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

@felix-hilden funny, like others i just find about this repo today, kudos, following what i read in the first post, is this library currently working in any way? or there should be work done on it first?

<!-- gh-comment-id:567649215 --> @thepixelabs commented on GitHub (Dec 19, 2019): @felix-hilden funny, like others i just find about this repo today, kudos, following what i read in the first post, is this library currently working in any way? or there should be work done on it first?

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

Author

Owner

Copy link

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

Yes it is, @pixelicous! Some updates to the Web API have been made by Spotify and the documentation is a bit wonky, but most of the functionality that is implemented works as far as I know. It sure does need some work, but don't let it stop you from using it. Or have a look at some of the updated versions if you want!

<!-- gh-comment-id:567673711 --> @felix-hilden commented on GitHub (Dec 19, 2019): Yes it is, @pixelicous! Some updates to the Web API have been made by Spotify and the documentation is a bit wonky, but most of the functionality that is implemented works as far as I know. It sure does need some work, but don't let it stop you from using it. Or have a look at some of the updated versions if you want!

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

Author

Owner

Copy link

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

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

<!-- gh-comment-id:567767321 --> @Harrison97 commented on GitHub (Dec 20, 2019): 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

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

Author

Owner

Copy link

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

@Harrison97 could you post this also to the second issue #406 where we are choosing the successor so we can discuss the different options?

And do note, that I am the new maintainer! Plamere has been very inactive, and does not have access to the PyPI or RTD project anymore.

<!-- gh-comment-id:567816886 --> @felix-hilden commented on GitHub (Dec 20, 2019): @Harrison97 could you post this also to the second issue #406 where we are choosing the successor so we can discuss the different options? And do note, that I am the new maintainer! Plamere has been very inactive, and does not have access to the PyPI or RTD project anymore.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

feature/2026-02-changes

feature/invalid-uri-warning

feature/refresh-endpoints

doc-deprecations

revert-synchronize

v3

run-tests

bugfix/1149-change-cache-name

2.23.0

v3_oldprsonly

2.26.0

2.25.2

2.25.1

2.25.0

2.24.0

2.23.0

2.22.1

2.22.0

2.21.0

2.20.0

2.19.0

2.18.0

2.17.1

2.17.0

2.16.1

2.16.0

2.15.0

2.14.0

2.13.0

2.12.0

2.11.2

2.11.1

2.11.0

2.10.0

2.9.0

2.8.0

2.7.1

2.7.0

2.6.3

2.6.2

2.6.1

2.6.0

2.5.0

Labels

Clear labels   

api-bug

  

bug

  

dependencies

  

documentation

  

duplicate

  

enhancement

  

external-ide

  

headless-mode

  

implicit-grant-flow

  

invalid

  

missing-endpoint

  

pr-welcome

  

private-api

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

spotipy3

  

wontfix

No labels

api-bug

bug

dependencies

documentation

duplicate

enhancement

external-ide

headless-mode

implicit-grant-flow

invalid

missing-endpoint

pr-welcome

private-api

pull-request

question

spotipy3

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/spotipy#240

No description provided.