Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add nix flake #561

Closed
wants to merge 2 commits into from
Closed

feat: add nix flake #561

wants to merge 2 commits into from

Conversation

getchoo
Copy link

@getchoo getchoo commented Aug 10, 2023

like the title says, this adds a nix flake which includes a dev shell and packages for both macos and linux! this should provide an easy way to install the app on both platforms, a stable interface for reproducible builds across the board, and easier onboarding for contributing through simple development environments. i've tested it on both systems and it works great :)

part of #497. the expression i based this on can be found here in pkgs/modrinth-app

@intergrav intergrav mentioned this pull request Aug 10, 2023
distribution/default.nix Outdated Show resolved Hide resolved
@getchoo
Copy link
Author

getchoo commented Oct 20, 2023

rebased onto latest master. i've also made a few random changes, but the only really important one is the adoption of naersk for building the package over nixpkgs rustPlatform - this was mainly done to reduce maintenance burden by not requiring the cargo deps checksums to be updated anymore, only pnpm

Copy link

@pauliesnug pauliesnug left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could do with some improvement, i think that flake-ifying everything makes the most sense rather than sticking with default.nix schema. default.nix schema would make sense if the build system was more complex, but right now we just need an input like crane for rust and another one for node and it would be up an running. if backwards compatibility is necessary, then you can use flake-compat. other than that, everything else seems good :3

@getchoo
Copy link
Author

getchoo commented Oct 22, 2023

this could do with some improvement, i think that flake-ifying everything makes the most sense rather than sticking with default.nix schema.

everything is in a flake currently. the default.nix file is just named that since it made the most sense to me (as it's the main unwrapped derivation, and default.nix/wrapper.nix is a somewhat standard layout in nixpkgs).

but right now we just need an input like crane for rust

we have naersk already

another one for node

as this project uses pnpm, there isn't really an input for it. instead, i've used an in-house method (that is also used by a few other packages in nixpkgs) as shown here. minus the verbosity, it offers basically the same features as something like buildNpmPackage/buildYarnPackage, where you only need to update the outputHash when the pnpm lockfile is updated

it would be up an running

it is running fine currently. the only issue right now is with the app itself, where i've noticed extremely long build times and/or OOM triggers when builds don't have a cache (see this workflow for example of an uncached build taking extremely long). if your machine can build it though, it works :)

if backwards compatibility is necessary, then you can use flake-compat.

im fine adding this if people want it, i just rarely ever use it personally lol

@pauliesnug
Copy link

@getchoo ah yeah this looks much better now, i think when i previously reviewed this the nix sub directory confused me but now this makes sense. maybe we could streamline this process using a js script that builds everything the way we want it, instead of specifying the configuration for tauri etc. in the nix/default.nix and for every future package manager.

@getchoo
Copy link
Author

getchoo commented Nov 11, 2023

maybe we could streamline this process using a js script that builds everything the way we want it, instead of specifying the configuration for tauri etc. in the nix/default.nix and for every future package manager.

there isn't much in nix/default.nix that is platform agnostic. it's following the standard process of fetch pnpm deps -> run pnpm build -> cargo build, just in the nix ™️ way. the only thing that could really be scripted is the process of building the frontend before running cargo build, but honestly it's one extra command so i don't think that kind of abstraction is needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants