Open tobifroe opened 5 days ago
Hi @tobifroe! Thanks for the interest! Yes, the plan for sure is to create a nix package for the client. Very soon here there's going to be a pretty big overhaul to the app version as I'm slowly migrating the client over to tauri v2 from v1. Tauri v2 also includes the option for android and ios apps. Tauri provides docs on a ton of different packaging options for v2 and I'll certainly try to nail down a working and distributed version for as many as possible. Because of all these options, getting a nix variant going should be pretty doable.
https://v2.tauri.app/distribute/
I'm about 3/4 of the way through development on the new 0.7.0 release which is where the initial support for v2 is going to be rolled out. A large component of this process has been building github actions to build and distribute these various editions on releases being created. You'll see jobs for flatpak, snaps, android etc...
https://github.com/madeofpendletonwool/PinePods/actions
Nix notably isn't one yet. In theory there won't be any maintenance if the automation is built right. Package up the app into the nix package and auto push to the right place automatically on release. So, all that said, by all means, if your willing and able to take a crack at packaging the client and building some automation it would certainly be greatly appreciated. If you want to create a fork create one off the 'tauri-v2' branch as that's the one with tauri implemented correctly for version 2.
I don't know a ton about nix packages right off the top but I'm assuming you might need a deb package or something like that as a base for the package on nix. If so, the build tauri clients job might need to run first to actually create the deb package first
https://github.com/madeofpendletonwool/PinePods/actions/workflows/build-tauri-clients.yml
Finally, quick note of clarity: I'm referring to the client here in all this. Which connects to a pinepods server to essentially act as your player. You might be talking about the server and web frontend. So there's two parts to Pinepods. The container server and the client. You don't need the client, because the web version that comes with the container does almost everything the client does save for local podcast downloading. The client is just a way to connect to your sever natively from your computer and soon to be phone. Currently the pinepods server only works in containers. I'm certainly not opposed to other distribution methods for people to run the pinepods server outside a container but there's certainly quite a few moving parts that will need to be accounted for with a binary for pinepods to run outside container.
The dockerfile
https://github.com/madeofpendletonwool/PinePods/blob/main/dockerfile
runs a startup script that runs a supervisor config.
https://github.com/madeofpendletonwool/PinePods/blob/main/startup/supervisord.conf
That config runs the frontend, api backend, and cron for some periodic jobs. For the pinepods server to run outside container those 3 would need to be accounted for in a nix package.
Additionally a database and valkey/redis server is needed
Let me know your thoughts or other questions you have, Thanks!
Thank you for all the clarification, that helps a lot!
I was also talking about the client, I think it's more important than deploying the server with Nix (which would be cool regardless).
Getting a package into the Nix package registry is as simple as opening a PR to the nixpkgs repository. Just as an example of what a Nix package can look like, here's one I maintain: klog-rs Nix package It contains the instructions needed to install the package and that's it. In that case, we just build a single Rust binary from source.
As far as packaging the PinePods client, we have a couple of options at our hands for Nix. The most pragmatic ones imo would either be
A couple of weeks (I think?) ago, cargo-tauri.hook landed in unstable nixpkgs. In theory, it should be pretty easy to just build PinePods from source with it. If that's not feasible for any reason, we might as well just download the AppImage. There's a stable hook that wraps AppImages and let's you create additional stuff like desktop files with ease.
As far as automation goes, there isn't too much to do on our side. Once the initial PR is merged, a GitHub bot (maintained by the Nix community) will open PRs to Nixpkgs once a new GitHub release is created. He'll ping the package maintainers and merging can be done with a single comment in the PR as long as all the checks turn green. You'll find examples in this filtered PR view.
If you don't have any objections, I'll try and get a Nix package working from the tauri-v2 branch in the next couple of days. :)
Ahh, I see. That all makes sense. Reminds me of the workflow for Flatpak. Well that's great. That really does seem like it'll honestly probably work great. Shouldn't matter how it's being built if tauri obfuscates away the complexity there. It'd be great if we could build from source no doubt. And I think that seems feasible.
Let me know what other questions you have, more than happy to answer them.
One I'll answer right away is with dependencies. You can take a look at the dev guide for installing what you'll need to compile the app
https://www.pinepods.online/docs/Developing/Developing
And Tauri should of course take care of pretty much anything else you need once you pull the repo, cd to the web/src-tauri dir and cargo tauri build
Eager to see what you come up with thanks again!
I saw that the ToDo section in README.md mentions creating a Nix package, I couldn't find an issue related to that though. I'd like to take this on if it's still wanted, I could potentially maintain the package too.