search

spotipy-dev / spotipy

A light weight Python library for the Spotify Web API
http://spotipy.readthedocs.org
MIT License
5.05k stars 960 forks source link

Is under development? #387

Closed Saphyel closed 4 years ago

Saphyel commented 5 years ago

Hello! I was thinking to check out this project but I don't see any activity in the last 2 years... is abandoned ?

idofr commented 5 years ago

Had the same worries but I'm just starting to use it and it looks nice enough to use. Worst case you can always submit a merge request.

I already found what I think to be a small problem, but I'll start another discussion for that

marioortizmanero commented 5 years ago

We should move everything to a fork since it really seems to be inactive. #211 is killing me. What fork is the most popular one?

Saphyel commented 5 years ago

I was thinking to create a new project base on the new Spotify API in beta and python 3.7 ready.

CipherTheDev commented 5 years ago

I just forked the project and a bit of help we could update it to a brand new one.

Saphyel commented 5 years ago

There is like 400 forks already... Anyway I think will be best a new one that is easy to switch from this one as a 1st version. So I'll follow this approach.

felix-hilden commented 5 years ago

It's nice to hear others having a similar concern. The author's email is not valid anymore. A bit ago I used this source to begin a small related project with the intention to include the library as a submodule, but seeing this discussion I think it's appropriate to pitch in my two cents. And I see @Saphyel and @pastaboy2131 have already started their own contribution!

There are lot's of forks, but if I'm not mistaken a large number of them have been used for pull requests for the original repo and such. At least I didn't find a fully up-to-date version.

A number of things bother me in the current state:

And I'm sure you have your own. But I've tried to address these concerns in my reimplementation. It is still in its infancy, but next I plan to add types representing models returned by the Web API and proper documentation in the near future. And Saphyel's access token as a dataclass seemed like a great idea.

I would love some input on my code too, seeing there are other committed people here as well. Maybe we can get a longer discussion going.

Cheers! Felix

CipherTheDev commented 5 years ago

@felix-hilden Thank you, I would love to help and contribute to your project as well.

I'll be updating mine soon as well and I agree, the code is too long and hard to read, the author could have just created sub-modules for the main module. What i am planning to do is to fully update the modules and make them more easier to read and/or modify.

felix-hilden commented 5 years ago

That's terrific to hear!

I found that using multiple inheritance to create the Spotify type was just the thing needed to clean the huge object up, at least from the development perspective. A base class with all the utilities, from which a number of classes implementing the API inherit, and finally a single class inheriting all of them. Together with renaming the methods I think I achieved a sensible result.

It required some time though. So I'm thinking that if you already have an implementation in the works, just not pushed to GitHub, I'd love to see how you solved the problem concretely. Then perhaps we could have an even better implementation as a result, the best of both worlds. But if you are still planning, it could save you quite the slice of time to at least consider my implementation and the (necessarily present) shortcomings of that. The rewrite required a tedious amount of going through the API spec, general refactoring and fixing documentation and odd code. Just unnecessary work, which could be avoided. Whether you think the multiple inheritance solution is the right one, it's just a copy-paste away from the old single class, but significantly improved in other ways.

Saphyel commented 5 years ago

@felix-hilden I do have more code done but not pushed yet because life keep happening... I didn't expect someone taking a look to my work at this stage to be honest I'm doing this because I have a side project in mind and requires this library and I want it work with python 3.7 and with the less bugs possible.

I'm planning to make it work with Github Actions to make sure it's a valid build and obviously with the lower complexity possible.

Thanks for your words and I do not have a clue what else I'm gonna do different.. I just do what my tests lead me to.

CipherTheDev commented 5 years ago

@felix-hilden

i agree with you, the multiple inheritance just made things worse for the project as i had to rewrite some code that i will update my fork to.

What i also had done is divide some code into sub modules to improve readability and/or performance. I'll definitely would love to help yours out as it is difficult doing it by one person. Even copy and pasting then making the readability better is better than nothing. There is no code documentation on the main project as well. I am adding this into mine, I am more than happy to create a new documentation for you as well. I'll consider your implementation and will most likely use it in mine if it is alright :)

I'll be updating my fork on the weekend as the weekdays i am busy.

more than happy to help you out :)

felix-hilden commented 5 years ago

@Saphyel Yeah, I guess life happened to @plamere as well 😄 no worries. But I think if you are looking to make the code bend to your side project's and it's tests' will, it could be best as a separate thing. Though I'm looking forward to seeing what you came up with! Also, GitHub Actions looks interesting, I hadn't heard of it before.

@pastaboy2131 Whoah thank you! Of course it is ok to use my implementation, any part of it. I would be honored. And I would gladly welcome any functional contributions as well, provided that my ego can let go and think about the common good for once 😆 With my point on multiple inheritance I was referring to my reimplementation, so I'm not quite sure what you mean. There is some documentation in the main project and loads of examples, but I think they could be significantly improved - not least with mixing Python 2 and 3 syntax.

This is starting to look promising. Can't wait!

marioortizmanero commented 5 years ago

Felix I really like your implementation myself, but if you're going to upload it to PyPi you should think of a better name to use to avoid confusion between the older implementation and yours. Maybe since it supports python 3.6 only, you could name it spotipy3? I don't know

Also, I'll help you out a bit when I have time, I hope I can be useful.

Saphyel commented 5 years ago

@felix-hilden no, it would be abstract I don't like my projects knowing too much about the other projects.

So far I only did a client class with 3 different endpoints with all the models needed for them. So it would be easy to extend/update

felix-hilden commented 5 years ago

@marioortizmanero Thank you! Yeah that would be the logical next step once we have something resembling an actual package. And spotipy3 could very well be the name, at least 'spotipy' is a very fitting name for a Python package. I'll continue the work on models today.

marioortizmanero commented 5 years ago

By the way I wanted to let you all know that there's a fairly popular branch: https://github.com/Harrison97/spotipy by @Harrison97, in case you want to contribute there instead. The only problem is that issues are disabled. Harrison, do you mind turning them on?

There's quite a lot of forks I don't know what to do haha

Edit: although his take seems to be different. He just cleaned it up and merged some PRs but didn't rewrite much

felix-hilden commented 5 years ago

That's good to know! And it's nice that someone has taken the time to care for this repository and its contributors 👌 I still think the rewrite is warranted, but maybe something in the merged pull requests or other cleanup might be useful to incorporate. I didn't look very carefully into what was actually done.

CipherTheDev commented 5 years ago

I agree with @felix-hilden a rewrite is still required since the whole git is outdated and written in a bad manner, forked with Harrison is good enough for now but in future releases i believe in a version 3 and Tomorrow @felix-hilden I'll be free and contributing a lot :)

felix-hilden commented 5 years ago

I have created issues under my project to mark some places where attention is needed the most - in my opinion anyway. I would appreciate a discussion there, as this thread is becoming a bit lengthy already. Here the essential has been said. Feel free to post additional issues too! Now let's get this thing rolling.

The answer to the question "Is this repository under development?" is a definite "No." But different versions are being developed! To summarise in the order of announcement:

davidt99 commented 5 years ago

@felix-hilden you can add my fork as well, it's mostly rewritten. I'm almost done, the only APIs that are not rewritten is the library and browse APIs.

CipherTheDev commented 5 years ago

@felix-hilden I am working on the documentation and will request a review soon, I'll perform bug hunting soon.

Harrison97 commented 5 years ago

@pastaboy2131 Please make a PR on my repo:

https://github.com/Harrison97/spotipy

felix-hilden commented 5 years ago

Nice!

Don't know where I should put this information, so might as well put it here. I'm away for the next five days, but goahead and PR if you have something! I'll look at everything when I get back. Back now.

CipherTheDev commented 5 years ago

I'll perform a PR soon for both of the projects. just working on examples now.

Saphyel commented 5 years ago

I updated my project with 3 endpoints so far https://github.com/Saphyel/spotify-api sorry I changed way too much the original project but the test shows how it works and the expected result.

Looking at this issue that is now almost 2 month old I think is very clear that this project is dead.

itzeddie commented 5 years ago

Just wanted to let people know I came across another Spotify wrapper today that seems to work pretty well for me so far utilising Python 3.7.4; https://github.com/omarryhan/pyfy. Last updated in June 2019.

rijobro commented 5 years ago

Did anyone decide which would become the default fork to use? I suppose everyone wants to use their own (for prestige), but I think we should just pick one and plough on! And naturally make use of PRs, issues and projects.

felix-hilden commented 5 years ago

@rijobro In the absence of an agreement, it should be the individual's choice what to use. One of the repositories will perhaps grow more than the others, but until then pick one that suits you. The approaches have been different and they will compete - not just with users but willing contributers as well. Then, let the cleanest, most maintainable, easy-to-use and feature-rich package emerge.

I'd love to hear your thoughts on our code if you're willing to contribute. The already established pyfy seems like a great option too if you're only browsing the options as a user.

rijobro commented 5 years ago

Sure, but whilst I get that, it's a bit of a shame not to collaborate since we're not in competition with each other! And new people arriving on this (like me), probably aren't going to click through all the hundreds of forks on this repo to figure out which is the most active.

Not saying I know what the correct answer is, but it seems like a shame for everyone to develop in their own corner.

felix-hilden commented 5 years ago

I agree, but in this thread there are just a few repositories that have been announced. That's a lot less than the four hundred forks of this repository.

jacobwells97 commented 5 years ago

Which fork is currently the most fully featured?

@felix-hilden has the most active fork currently, with commits from only a couple of days ago. @Harrison97 has many more contributors and commits, but hasn't been updated in 2 months. Why wouldn't you try to merge projects? Pick a few people, including @felix-hilden and @Harrison97 to administrate pull requests in case one goes inactive for a bit.

This is a problem with a lot of demand. If I build an app using your wrappers, I don't want to worry about picking the project that stays the most up-to-date with the Spotify API, or have to find/adapt to a new wrapper. You all work at the frontier of this issue, why are you all competing instead of trying to combine efforts? Working from one repo would guarantee fuller features and potentially increase the lifespan of the project. If your goal is to offer the most/the most up-to-date access points to the Spotify API possible, then it doesn't make much sense to be in competition over the same functionality.

Right now it seems like someone is wasting effort, though, if all of you are rebuilding the exact same functionality in different places. It definitely makes my life harder trying to figure out which wrapper to bet on.

felix-hilden commented 5 years ago

Different approaches have been taken, @jakesmells. But I agree, having a number of contributors would be very beneficial for the project. In terms of lifespan and also discussing the directions to go in.

Harrison has very kindly been taking care of the original repository and its potential contributors, while in my opinion it was easier to design and rewrite the whole thing from scratch. I think the approaches are sufficiently different from each other to warrant different repositories. If Harrison believes developing the original code is worth it, he and likeminded people can pursue that. I am neither interested in it, nor would I dare to create a pull request overwriting his whole code base. Though I admire his commitment.

Perhaps the following summary helps in choosing a wrapper. 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. It's up to anyone to decide whether this structure adds value or just complicates things. In my opinion it makes development easier. For example knowing what a particular response contains and which are all the possible scopes that are available is essential information. Pyfy provides two kinds of clients, asynchronous and synchronous in addition to providing some additional structure too.

In terms of Web API features, I have tried to read the code of pyfy too, but it seems to me that pyfy and Harrison's fork are missing some endpoints like uploading a playlist's cover image. But I might have missed something. Regardless, I have implemented all of them. You can also look at the first tutorials of each package to get an understanding of the style imposed on the developer that uses each package. Harrison, felix and pyfy.

If Python versions are in consideration, Harrison's version supports the oldest ones, all the way from Python 2. pyfy supports Python 3, although it is not explicitly required in the setup script. I have chosen to require Python 3.7 or above, because Python 2 is on its way to the burial ground and the latest Python versions have introduced many useful features. Hope that helps.

felix-hilden commented 4 years ago

Hi, I am now the maintainer of Spotipy on PyPI thanks to a name transfer. We should figure out what to do with the package. Please have a look at the issue linked above and voice your opinion!

felix-hilden commented 4 years ago

There's an issue to choose the successor of Spotipy! Please nominate your libraries if you are planning on actively maintaining them and going for PyPI!

idofr commented 4 years ago

Well... does it depend on your plans? where would you like to see this repo?

felix-hilden commented 4 years ago

I certainly want to continue the maintenance on PyPI as agreed in #404! I have nominated my version, which I'd of course like to publish. Everyone can write their own versions on GitHub, but the issue is specifically which repository to choose to carry on the Spotipy name in PyPI. Did I answer your question?

stephanebruckert commented 4 years ago

Good news, spotipy is under development again. @ritiek and myself are taking care of it for the moment. The short-term plan is to:

Then we can start working on harder problems and missing endpoints again. Any contribution is always highly appreciated! 🙏