Further development of tidalapi/python-tidal

[tehkillerbee]

Hi @tamland

As you know, we use your API for Mopidy-Tidal, and I am sure there are others relying on it for their own Tidal tools.

There are currently several bugs that result in tidalapi not functioning anymore. #130 by @blacklight fixes this but it has not been merged as of today and this makes it difficult to rely on tidalapi. Would you like more assistance with handling PRs and/or further development?

[tehkillerbee]

@tamland Just a quick comment, in case you have overlooked the previous one.

I would like to offer being a maintainer of this project and I am sure there are a few that would like to help contributing as well to keep it alive :)

[tamland]

@morguldir maintains this project, but happy to add collaborators if everyone agrees.

[tehkillerbee]

Thanks, yeah I see that now. For some treason I thought you and him was the same person. :)

Judging from his github activity, I'm afraid he has abandoned the project. Are there any other maintainers left?

[evan-goode]

Hi @tamland @morguldir, any updates here? Projects like these that open up proprietary services are exciting, but they tend to break often due API changes (whether those be made oblivious to our work, or out of malice), so it's absolutely essential to have a team of active maintainers who can push out fixes quickly.

Thanks to all who have contributed to/maintained this library.

[tamland]

@blacklight and @tehkillerbee have access to the repo now. As I said: let me know if you need anyone else added :)

[blacklight]

@tamland thanks, I've received the invitation now.

I guess that at least one of us will probably need our tokens to be added to the PyPI project too in order to push new releases?

[tehkillerbee]

@tamland Thanks, perhaps we should add @2e0byo as well? PyPI access would also be necessary so we can update the PyPI release.

[tamland]

I need pypi usernames to add people there

[evan-goode]

It may also be worthwhile to automate PyPI releases through GitHub Actions: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

[JoshMock]

Related: the AUR package is also without a maintainer. I might consider adopting it if no one else does, since I've been meaning to get more familiar with making AUR packages anyway.

It might also be possible to hook that up to a GitHub action, since @evan-goode mentioned it.

[2e0byo]

@JoshMock You can definitely hook up aur releasing (or anything) to GH actions. On the other hand the only thing which needs to change on release is the tag and checksum, unless any dependencies are added (currently this is a wonderfully clean library with none at all). One option would be to make a python-tidal-git -git package which just pulls the latest commit from git and installs, rather than having fixed releases. In that case there's (almost) nothing to do to maintain it, assuming the git source always builds. (Some aur helpers, like paru, can figure out when a new commit is available upstream.)

In any case IMHO downstream packages don't belong in the repo and probably not in the CI. But if you want to automate things you can use a webhook when upstream releases to trigger ci in your own repo. (We'd have to add a webhook here to our hypothetical release ci, but that's reasonable I think.) Alternatively you can just set up a workflow to run daily and check for updates.

@everyone Again just a random opinion, but releasing to pypi from CI makes sense I think if (i) the maintainer has access to the repository's secrets to store the credentials, and isn't worried about them leaking, and (ii) there's some agreed push-to-release strategy. (Otherwise it's 'what's the magic word again?'). (i) strikes me as the problem here: I don't have access to the secrets of this repo, and I shouldn't (it's someone else's repo); but thus I'm not going to hand over my credentials for anyone who triggers workflow X to use either. (Obviously only those with push access could do so, but it's more that the secret is out of my control, because I can't edit repo secrets, which just isn't good bookkeeping: I'm responsible for looking after that token.) A fortiori, on reflection, using personal tidal access tokens to run the tests in CI.

One solution would be to create a Pypi user specifically to publish python-tidal, and then for tamland to add the required secrets to the repo. In any case if anyone's going to be able to publish it probably shouldn't be me as I've yet to contribute any code.

@tamland thanks for the invite! I promise not to be an idiot ;)

[JoshMock]

Makes sense. I'll see about adopting the AUR package and managing it separately. 🖤

[omni6]

Thank you all!

[tehkillerbee]

I need pypi usernames to add people there

Sure, feel free to add my PyPi username. I will send you an email with the details.

I have no good suggestions on how to proceed with PyPi releases, but it would be nice if it can be streamlined to reduce the work needed to maintain tidalapi.

@2e0byo Could poetry be a solution for this, as you implemented with Mopidy-Tidal?

[2e0byo]

Certainly, poetry makes releasing a single poetry publish --build. I'm happy to pr a migration to poetry if you like and no-one objects. It's less of an issue here than for mopidy-tidal as tidalapi has no runtime deps at all.

That only improves the tooling though: if you want releases to happen automagically we need to solve the secrets problem; I.e. someone's token needs to be in the repo secrets.

If we want to make frequent ci releases happen, one option I use elsewhere is conventional commits. Every time you merge to master a job runs and if relevant a new release with the right version number (patch for fixes, minor for changes, major for breaking changes) is created on github and pypi. Again I'd be happy to pr the ci, but we'd need to solve the secrets problem, and agree to use conventional commits. Again a system I personally like, but this isn't my project (although I do mean to contribute).