Skip to content

Conversation

@Jakoma02
Copy link

This PR enables building prisma-engines from source using the Nixpkgs derivation instead of relying on prebuilt binaries. This is useful to me because I am trying to use prisma on the armv7-linux system, which is not officially supported by prisma (so there are no official prebuilt binaries for it), but it can be built successfully using the derivation in nixpkgs.

Building from source can be enabled by using prisma-factory like this:

prisma-utils.lib.prisma-factory {
    inherit pkgs;
    # leave the hashes empty, nix will complain and tell you the right hash
    usePrismaFromPkgs = true;
    prismaEnginesGitHubHash = "";
    prismaEnginesCargoHash = "";
    npmLock = ./package-lock.json;
    # Lockfiles of other package managers are supported as well.
};

Building from source works by using the prisma-engines_6 package in nixpkgs and overriding the source with the specified commit from GitHub, overriding the rust toolchain with the one specified in the rust-toolchain.toml file in the prisma-engines source code, and overriding cargo dependencies with ones specified in the source code. For overriding the rust toolchain, the oxalica/rust-overlay flake is used to obtain the toolchain corresponding to the rust-toolchain.toml file. This is necessary because newer versions of prisma-engines might require a newer toolchain than the one present in nixpkgs.

It must be noted that because the build process might vary between various versions of prisma, this approach is not always guaranteed to work and will only work for versions of prisma that successfully build using the nixpkgs derivation. Most notably, only major version 6 of prisma-engines is supported right now, as I do not have the bandwidth right now to fully test it for prisma-engines 7 which I am myself not using at the moment (nixpkgs has prisma-engines_7, but it seems that it does not build all the components that are expected in components.nix and as is it will probably not work together with prisma 6).

Because the tests for existing fetchers use version 5.1.1 of prisma-engines, and building from source is only supported for major version 6, it is not possible to use the same for lockfiles for testing. For this reason, I include the directory pnpm-prisma-6, which contains a pnpm lockfile with prisma-engines 6.18.0, used to test building from source.

Included Changes

  • Added the functionality for building from source to prismaFromPkgs.nix
  • Modified prisma.nix to recognize and handle usePrismaFromPkgs = true;
  • Extracted the toExportStyle and mkEnv helper function to a separate file env.nix
  • Added rust-overlay as flake input and passed rust-bin as an argument to prisma-factory
  • Added the pnpm-prisma-6 with a pnpm package depending on prisma-engines 6.18.0
  • Added a test testing the prisma built from source
  • Updated the flake lockfile (needed to have nixpkgs with a reasonable recent derivation of prisma-engines)
  • Updated the obsolete shell package pkgs.nodejs-18_x with pkgs.nodejs_24
  • Updated the readme with documentation of the feature

@VanCoding
Copy link
Owner

Hi @Jakoma02

Thanks for taking the time to make this PR!
After thinking about this one for a while I'm still not sure if it's good to make building prisma engines from source part of the scope of this project.

I can see why you would want to add it, since apart from fetching & patching the binaries we also have code that can detect the engines version from various lockfiles (which is the part you're interested in here). As an alternative, nix-prisma-utils could probably also just expose these library functions for outside use, so that the rest can be handled in a separate flake.

What makes me hesitate is that supporting building arbitrary versions of prisma-engines is a much harder task than just patching them. The demand for building from source probably is also smaller.

This doesn't mean I'm completely against accepting this, but I think I need a bit more "convincing" work first :D

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants