first party nix (flake) support

[HannesGitH]

solves #54

i already tried that way back, but now that i understand nix' inner workings much better i though i'll give my previously failed missions another shot. and it worked, whoop whoop.

as nixpkgs already has rquickshare available, feel free to close this pr.

i just wanted to do this as a challenge. But it has two major differences to the variant in nixpkgs:

• if you want to have first class support (either for ci pipelines, for reproducible builds in general, or just because we can), here you go, nor more relience on downstream nixpkgs
• the variant in nixpkgs simply wraps the prebuilt appimage (from your github releases) and therefor (besides other drawbacks) only supports x86_65-linux. this one builds itself from source and can therefor be used on many platforms (i myself tested on aarch64-darwin)

but if you dont want to see any nix in your repo, sure thing, just close this PR, no worries :) maybe ill try to add it to nixpkgs then

[Martichou]

Thanks a lot for the work you've done here!

I have some question related to the changes, but I also have a need to understand a bit for Nix. How does one build RQuickShare using those files?

You're speaking about CI, what's the expected out file format to share or something?
(excuse me but I have absolutely 0 knowledge about Nix... and I need to understand what's in this repository :))

[HannesGitH]

Thanks a lot for the work you've done here!

Sure thing! :) As I said it was primarily as a challenge for myself so no bad feelings if you discard this pr :P

I have some question related to the changes, but I also have a need to understand a bit for Nix. How does one build RQuickShare using those files?

Okay, if you want a deeper dive i'm probably not the BEST person to ask, but as a very short introduction.:Nix is a programming language for declarative, reproducible package management. Rust (with its cargo.lock) and pnpm (with its .lock) already have a rather robust approach, but nix will guarantee reproducibility for everything (that might, depending on who you ask, come at the cost of ease of use tho). But there are currently two similar, yet different approaches: the official, default.nix, and the newer, albeit experimental (tho rather field tested and stable no idea why it's still called experimental), flake.nix, way. As you see i'm a friend of the latter as it brings more guarantees and allows for unified standalone 'flake' repos.
The flake.nix therefor is the one and only entry point in this case. For anyone having nix installed, no matter if only the nix package manager or fully fledged nixos, has to enable the experimental flake support and can then use everything that has a flake.nix file somewhere to deterministically build binaries from the provided source. For example everyone can run this program by running nix run github:martichou/rquickshare (after merging this pr ofc) which intern fetches this flake file along with all the other source code and then runs the build instructions in the flake file for the default package, puts it to you system and runs it. Similarly nix build does the same, without the running, nix shell as well but also adds the resulting binaries to you current path, and nix develop opens the devShell provided in the flake. You can ofc run local flakes simply by nix run . or similar.

You're speaking about CI, what's the expected out file format to share or something? (excuse me but I have absolutely 0 knowledge about Nix... and I need to understand what's in this repository :))

Well, for nix users you don't have to do anything, that's partially the point of source based package managers, but the builder (in this case the tauri.hook given to the rustPlatform.buildRustPackage ) can produce multiple binaries depending on the system type, in tauris case per default it will build .app for darwin and .appimage for linux, windows isnt really supported by nix afaik, tho you could crosscompile to target that aswell but idk..
You could ditch the whole ci pipeline and replace it with a matrixed nix build followed by uploading the artifacts (in a results symlinked folder)

Hope that helps :D

[HannesGitH]

Swapping the CI for a nix one (which just installs nix and runs the instructions in the flake via nix build) should be fairly straightforward.

If you are interested I could help you with that :)

[Martichou]

Thanks for the explanation! This does seems like it would be useful indeed :)

I'm going to merge this once you update the PR to include the link to the PR for Tauri 2 support.
But for the CI I'm not going to replace it, but having Nix in the repo as your prepared, is very welcomed ;)

[HannesGitH]

cool :)

the pr was just merged, lemme update this flake to not need my nixpkgs fork anymore, should be ready in ~5min

[taha-yassine]

Not entirely related, but could the work in this PR be upstreamed to nixpkgs to build from source instead of the current method that wraps the appimage?

[HannesGitH]

Not entirely related, but could the work in this PR be upstreamed to nixpkgs to build from source instead of the current method that wraps the appimage?

Yeah, thats possible, and I can also do that as well; but tbh I dont know the best strategy to do so as I dont want to simply copy all the logic, I already asked over at discourse

But feel free to open the corresponding package request issue over at nixpkgs (and include the discourse link and this pr) so it gets more attention and someone more knowledgeable can tell me the best strategy

[Martichou]

Just curious, what's the implication of upstream Nix for RQuickShare and this PR? Should both coexist or it is not worth it?

I'd be happy to merge this if this still has some value (faster update maybe?).

[HannesGitH]

tbh if you dont plan on using nix yourself and dont want to rely on me for maintaining the nix part of this repo i dont see much benefit besides it beeing easier to use different versions of rquickshare, including -yes- faster (possibly unstable) updates as one can run each and every commit (after the flake was introduced), provided the build instructions dont change (or one of us maintains the nix files to update the build as well).

this would in theory be possible with nixpkgs as well, but require some manual overrides inside a file.

on the other hand nixpkgs caches all of their builds, so simply running rquickshare the first time is probably faster (if you dont care about the version) when using the nixpkgs package

---

edit: i fear one would need to update the pnpmDeps hash as well as the cargo hash everytime new dependencies are added to pnpm or cargo, which probably happens from time to time and is rather unfortunate

[HannesGitH]

if you want to merge tho, let me quickly make some changes i used while making it compatible with nixpkgs

edit: done ✅

[Martichou]

Based on what you just said, I think I'd prefer not to move forward with this PR since it will be available upstream. And as you pointed out, I'm not going to use Nix myself and maintaining that would be quite a work to not forget it each time I update deps/add deps, ... :)

I'll keep this PR open until it is added upstream so that we don't forget to include it in the README once available.
Thanks once again for your time and work here 👍