MilesCranmer / rip2

A safe and ergonomic alternative to rm
GNU General Public License v3.0
27 stars 1 forks source link

enhancement: nix flake #35

Closed koalazub closed 1 month ago

koalazub commented 1 month ago

Prefacing by saying I'm cognisant of this being a meme and also leading into the rabbit hole of integrating every build system known to the universe.

Although it would be nice to have. I do understand if it's not a possibility

MilesCranmer commented 1 month ago

If it's just a file in this repo (and has an associated unittest for it) then I'd be happy to take a PR. I have no idea how nix works though so can't do it myself.

kanielrkirby commented 1 month ago

I can package it for Nix, I'm assuming it's just a simple cargo build. Flake should be pretty simple after that, just a callPackage. The way I've seen it done thus far is a flake.nix with the devShell, and a nix/default.nix with the package definition. I'll see about submitting a PR later tonight if that's cool.

kanielrkirby commented 1 month ago

Slight concern though, this would mean you'd need to update the vendor hash each time you deploy. There might be some way larger projects do that (something like nix-prefetch-url maybe?). I'll check around

koalazub commented 1 month ago

I can package it for Nix, I'm assuming it's just a simple cargo build. Flake should be pretty simple after that, just a callPackage. The way I've seen it done thus far is a flake.nix with the devShell, and a nix/default.nix with the package definition. I'll see about submitting a PR later tonight if that's cool.

Depends on how you structure it and the assumptions made such as whether we need it to be backwards compatible with nix versions that don't have flakes enabled(2.4 I think is when they enabled it by default). That's what I find to be the only reason to have a default.nix file

You can package and build in the same flake and run it based on whether you want to develop or build. I tend to build flakes with everything in it as I only need the phases followed by the devShell declaration to simplify everything. My skill issue lies with deployment as I've never pushed anything to nixpkgs before.

Slight concern though, this would mean you'd need to update the vendor hash each time you deploy. There might be some way larger projects do that (something like nix-prefetch-url maybe?). I'll check around

I think that's the best approach too

kanielrkirby commented 1 month ago

Didn't have as much time as I thought, tomorrow is my day off so I'll do it then.

But honestly the hardest part about sending it to nixpkgs directly is getting it reviewed before the other 6000 PRs and 8000 issues 😅

The concern with adding it directly to the repo is mostly for Miles and making sure he doesn't have to update the nix file each time manually. I'll have to see how other projects automate that step with maybe a git hook or workflow or something. Lemme know if you have inspiration anywhere for sure, didn't see many Rust examples in other CLIs (at least in the repo).

koalazub commented 1 month ago

Yeah totally understandable. You might be able to make the prefetch -> update the hash in an env var and then inject it into the flake? I haven't done that before so I'm just spitballing. I think a good source of inspiration would be https://github.com/helix-editor/helix/blob/master/flake.nix maybe? Or on a smaller scale: https://github.com/eza-community/eza/blob/main/flake.nix

The nice thing about nixpkgs is that you can approve it yourself and then it'll go through the publishing phase at some point. I did that for a package I wanted not too long ago. Plus their Matrix for devs is very helpful. I've got a bit of work that's time sensitive that I need to get done, but I'll definitely help when I can.

Hope that info was useful

kanielrkirby commented 1 month ago

Super helpful actually, didn't know about the self-approvals, and hadn't gotten time to take a look at Helix yet. Swore I checked eza but I suppose not. Nix community is just so massive, can pretty much never know everything haha.

So it turns out packaging is different between nixpkgs and within the repo. If you're using builtins.path to source the package, it'll handle the hash implicitly, which is why neither repo has one. So my misunderstanding there haha. Some of them just use naersk, makes the build process easier and abstracts the hash part, so I'll prolly just do that. My (like 3rd) misunderstand lol. We'll get there eventually!

kanielrkirby commented 1 month ago

Made a PR, lemme know if there's anything unordinary @koalazub, would be greatly appreciated.

koalazub commented 1 month ago

Thanks so much for spending time on this mate! Looks really good

kanielrkirby commented 1 month ago

Think it's time to close this one! @koalazub