search

librespot-org / librespot

Open Source Spotify client library
MIT License
4.75k stars 584 forks source link

Move Travis CI over to Github Actions #428

Closed sashahilton00 closed 3 years ago

sashahilton00 commented 4 years ago

I'm not too familiar with Github Actions, but from what I've seen, it's basically Travis but built into Github. We should move across to that when we get a chance as it's more streamlined & removes the dependency on a 3rd party platform. If someone is familiar with the Github Action markdown and wants to rewrite the .travis.yml, it would be much appreciated, otherwise I'll give it a go when I get some time to read up on it.

mainrs commented 4 years ago

I can tackle this down. We completely moved to GA over at https://github.com/Spotifyd/spotifyd. I can start working on it after my last exam at the start of february

sashahilton00 commented 4 years ago

Would be great if you could. I'm also busy until at least mid February. Also, not sure if it's the reason spotifyd isn't on crates.io yet, but librespot is now published, so it should be possible to publish spotifyd if desired.

mainrs commented 4 years ago

Yes, it was the reason. We did publish our latest two versions on crates.io :)

sashahilton00 commented 4 years ago

ah right, I'm blind

mainrs commented 4 years ago

Oh, btw: Is there some tracking issue for the work to split librespot into a library and a daemon? I couldn't really find a branch that you guys started nor an issue for it.

@sashahilton00 Can you assign me to the issue so it'll show up for me on GitHub?

sashahilton00 commented 4 years ago

I was just thinking about that funnily enough. There is one I believe, though I'll have to search for it a bit (currently out of office). As it currently stands, the work to separate out the library/application aspect is mostly done - the individual packages are listed on crates.io and ready to use. There is a separate repo (librespotd) that is intended for the daemon, but no work has begun on it yet. What will likely happen is the application part of librespot will be moved across to that repo in due course, with the intent of this repo being primarily a library, perhaps with a barebones application that just contains the basic features.

I believe we discussed this either on Gitter or in an issue briefly, but there is likely to be significant overlap between spotifyd and librespotd in terms of functionality, so it might be worth looking into combining efforts into one or the other.

mainrs commented 4 years ago

Ye, we briefly discussed it in https://github.com/librespot-org/librespot/issues/363. Maybe I'm remembering stuff wrong but I thought the idea was to split the audio backend into a daemon and let the library be a pure implementation of the protocol without all the audio implementations. Applications would then use the library to receive and send PCM data to the daemon.

~I might just mix up stuff at this point though.~

Based on the past x years of maintaining librespot, a chunk of the issues have been at the audio output level, ie. pulseaudio et al(sa), which have required multiple patches which added nothing to the core functionality of the program. The plan was to split librespot and librespotd, with the latter being a daemon that ran at system boot or similar, and dealt with the audio output bloat, along with the bells and whistles features, eg. zeroconf, websockets api for control, etc. librespot would then be the core library, with the aim of being as stable as possible, whose job it was to handle interaction with spotify servers and return data and pcm. If this were to be done, the benefits of a wrapper for various languages are negligible, as it would be simpler to just control via something like a unix sockets or websocket api, whilst also avoiding detracting from development time to maintain wrappers.

spotifyd does provide some other stuff as well though like password manager support and media key support using OS specific protocols. Not sure if that is stuff that might want to go into librespot itself. I'm generally in favour of merging as I think that would greatly benefit both projects. A lot of stuff is moving right now inside of the Rust ecosystem, especially the whole async/await and futures 0.3 related stuff, which probably needs larger code changes anyway.

sashahilton00 commented 4 years ago

Apologies, I should have been clear. The basic features would have essentially been the pipe output. W.r.t what goes into librespotd, I think the general consensus was that all the various bells and whistles go into librespotd. That would include things like password manager support and media keys, websocket servers and audio backends. Given how easy it is to use feature flags in rust, so long as we use them for the various bells and whistles, people can just compile in the functionality that they want.

mainrs commented 4 years ago

Ah, so the library would then, for example, fetch PCM data from Spotify and pipe it into librespotd. Then, depending on the backend the user would receive audio data. Is that correct? If yes, how would piping work on Windows. I don't think there are similar concepts floating around, but I might be wrong. Linux does offer a little bit more support for them with setting them up automatically. But I guess nothing stops you from using just a file.