[feat] upstream nix requirements to nixpkgs

thedavidmeister commented 6 months ago

Describe the problem

Not sure if this is a bug or a feature, it's borderline imo.

Basically what I expect is that when i use the cargo-tauri derivation from nixpkgs that i don't also have to copy and paste a bunch of additional prerequisites from the tauri docs in order to get things half working.

I say half working because I'm still running into bugs with cargo-tauri, especially on mac, one of which i already pushed a fix for https://github.com/NixOS/nixpkgs/pull/279771#event-11446551011

I also see that one of the dependencies, webkitgtk is marked as broken in nixpkgs on mac, but listed as a dependency on the tauri docs. I understand the nix docs say nixos rather than nix but it's pretty common use case for people working on linux/mac to be using nix rather than committing to a full nixos setup.

Additionally, I noticed that the prerequisites in the docs only work for a nix develop style shell, they don't work for nix run, say if I wanted to lift some standard tauri tasks into a package, the instructions don't cover that. This is because the additional steps of setting up the library etc. are limited to a shellHook.

Further, the prerequisites are missing required steps in the shellHook. We found that when tauri is built via nix there is a need to disable webkit compositing mode like export WEBKIT_DISABLE_COMPOSITING_MODE=1 in the shellHook. This seems to be some known tribal knowledge, as it appears in snippets from other people such as https://github.com/tauri-apps/tauri/issues/8535 but it's not listed in the prerequisites in the docs.

There are other issues like https://github.com/tauri-apps/tauri/issues/8535 that I expect are probably not issues with tauri itself, but some additional work that needs to be done on the nix side. At the moment it isn't clear where to put or discuss such a fix, would it just result in more documented boilerplate? or is there a way to codify it?

Stepping back a bit, I feel like the meta issue is that fixes to issues are being pushed into the tauri docs (or not) rather than some derivation that is directly maintainable and reusable downstream.

Describe the solution you'd like

Tauri maintains the derivation in nixpkgs with the same dependencies that it outlines in the documentation, so then there are no manual steps for consumers.

Alternatives considered

Another alternative would be that tauri maintains their own nix code separate to nixpkgs, such as an overlay or flake.

This would be fine too, the main problem to solve is to lift dependencies and other issues from docs and into nix-compatible code somewhere.

Additional context

No response

FabianLars commented 6 months ago

I think the main blocker here is that nobody in the tauri wg uses nix or nixos and i personally am not interested in getting into it either.

The docs were contributed (and are semi-maintained) by the community. And together with my prior statement we currently rely on them to also fix issues with it / keep it updated. Same for cargo-tauri, i'm not sure we even knew it exists (and i for one don't even understand it 😅).

I also see that one of the dependencies, webkitgtk is marked as broken in nixpkgs on mac, but listed as a dependency on the tauri docs. I understand the nix docs say nixos rather than nix but it's pretty common use case for people working on linux/mac to be using nix rather than committing to a full nixos setup.

Is it possible then to mark webkitgtk as platform specific? Because it is a hard dependency on Linux but indeed not used at all on macOS. But you're right, we should probably differntiate between nix and nixos (probably by adding a new nix section to macos. Or wherever we could fit it into the new docs.)

Anyway, i believe that for the time being this is something we have to rely on the community to maintain if they want to use it. Alternatively, if our docs are indeed that wrong we should consider to remove it / not migrate it to the new site (beta.tauri.app) until there's an actually working version. I know this is likely not the type of response you were looking for but there's only so much we can do with our current resources...

FabianLars commented 6 months ago

Actually, let me reopen this with the Help Needed tag for better visibility :)

thedavidmeister commented 6 months ago

@FabianLars this issue is about an approach, the nix community is large and there is a cargo-tauri pkg that i managed to update without much friction when i put a PR up

have you tried filing issues for these dependencies and other concerns upstream?

perhaps someone from the nix community would be willing to help

khionu commented 4 months ago

The ideal solution for Nix/NixOS users would be for Tauri to have a flake. Said flake could provide a basic devshell that user flakes could inherit, and that would import the essential packages. It could also export tauri-cli.

Normally, I'd say the flake should be in this repo, but it might be good for it to be in its own repo because of the sheer size of this one. Would make it easier to delegate stewardship as well.

ahkohd commented 4 months ago

I recently started using NixOS (x86_64-unknown-linux-gnu). I have a custom flake that I use for Tauri projects. How can I be of help?

flake.nix

{
  inputs = {
    nixpkgs.url = "nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay.url = "github:oxalica/rust-overlay";

  };

  outputs = { self, nixpkgs, flake-utils, rust-overlay }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs {
          inherit system;
          overlays = [ rust-overlay.overlays.default ];
        };

        toolchain = pkgs.rust-bin.fromRustupToolchainFile ./rust-toolchain.toml;

        packages = with pkgs; [
          cargo

          cargo-tauri

          toolchain

          rust-analyzer-unwrapped

          nodejs_18

          nodePackages.pnpm
        ];

        nativeBuildPackages = with pkgs; [
          pkg-config

          dbus

          openssl

          glib

          gtk3

          libsoup

          webkitgtk

          librsvg
        ];

        libraries = with pkgs; [
          webkitgtk

          gtk3

          cairo

          gdk-pixbuf

          glib

          dbus

          openssl

          librsvg
        ];

      in {

        devShells.default = pkgs.mkShell {
          buildInputs = packages;

          nativeBuildInputs = nativeBuildPackages;

          shellHook = with pkgs; ''
            export LD_LIBRARY_PATH="${
              lib.makeLibraryPath libraries
            }:$LD_LIBRARY_PATH"

            export OPENSSL_INCLUDE_DIR="${openssl.dev}/include/openssl"

            export OPENSSL_LIB_DIR="${openssl.out}/lib"

            export OPENSSL_ROOT_DIR="${openssl.out}"

            export RUST_SRC_PATH="${toolchain}/lib/rustlib/src/rust/library"
          '';
        };
      });
}

rust-toolchain.toml

[toolchain]
# You can use a stable channel. Tauri recommends using a Rust version of at least 1.64
channel = "nightly-2023-08-08"
components = ["rustfmt", "clippy", "rust-src"]
targets = ["x86_64-unknown-linux-gnu"]

ahkohd commented 4 months ago

Do we create tauri-apps/nix-flakeor a community maintained repo? Where can we maintain the flake I shared above and add support for darwin?

khionu commented 4 months ago

I asked on the Discord, and the TL;DR is that it should probably be made and owned by a member of the community first. I'd be happy to own it.

simonhyll commented 4 months ago

Yea the best path forward is to first make a repo community owned so that we see there's a real interest and that it's not just yet another feature request putting the burden of developing it on the WG.

The question of whether it then becomes part of the official tauri-apps organisation is really the question of who will maintain the project and whether the community is ok with relinquishing control of the project over to the WG. Once something becomes official it falls under the control of Tauri with all the checks and balances that comes with it, such as demands for proper reviewing of PR's, CI/CD, supporting the project, ensuring it's safe and stable, the works. The closer the project adheres to Tauri's demands the easier it'll be to transition into being an official project.

Note ofc that it's not impossible by any means to join the WG, if you own it @khionu and donate it to tauri-apps later, it could be seen as your contribution towards Tauri and qualify you for joining the WG if you so choose. Getting at least 2-3 WG members onboard with maintaining the project is a good idea. Getting the clear-to-go from the relevant domain lead is the final checkbox to tic I'd say (the development domain in this case, @lucasfernog, since the domain lead is the one that either creates or assigns a team to work on the project).

ahkohd commented 4 months ago

I have created a repo https://github.com/ahkohd/tauri-flake where we can all contribute to the flake.

I'm looking for a Darwin contributor and other reviewers. I can contribute to this, but I'll need to set up Nix first on my MBP; it will be faster if somebody already has this setup.

ahkohd commented 4 months ago

I asked on the Discord, and the TL;DR is that it should probably be made and owned by a member of the community first. I'd be happy to own it.

Oh I missed this, oops.