Cargo.lock is ignored in repository

[turtton]

Hello. I am currently attempting to create reproducible builds for the jan app using nix.
During this process, I noticed that the Cargo.lock file is not being committed within src-tauri.

This file has become essential for building Rust packages with nix, and Tauri also recommends committing it.
https://v2.tauri.app/develop/#source-control

@louis-menlo
I'd be grateful if you could explain the background of this commit and whether there's any possibility of restoring the lock file in the future.

[louis-menlo]

Hi @turtton, we did try adding lock files to the codebase, but then every commit ended up with lock file changes that were irrelevant and made the code change significantly harder to review. However, they're essential for build caching and the issues you mentioned. We're planning to have the CI/DevOps handle this automatically instead of manually pushing the changes.

[turtton]

Thank you for the quick response.
While I'm not familiar with Tauri, I have experience with Rust and GitHub Actions, so if there's anything I can help with in your future plans, please let me participate.

[louis-menlo]

This would be awesome!

[DuncanBetts]

I've also been trying to build this from source for NixOS today and, ran into the same problem.

I tried to get around it, for now, by generating a Cargo.lock file, but then ran into a further problem with that a MPC server, (rpmpc, something like that) uses a workspace and NixOS had difficulty with that. But, I think if there was a Cargo.lock in the repo a different NixOS build tool would have "just worked" - I'm not very familiar with rust.

I can run 0.6.4 using the AppImage, using the below packaging, but it'd be much nicer to build it straight from source.
I tried updating the below to 0.6.5 and also tried 0.6.6 but Jan just crashes (on X11 btw, it could be my custom GTK theme causing that, I haven't looked at the error - I just reverted to 0.6.4).
I haven't tried simpler approaches to using AppImage's on NixOS either (I'd far rather build from source).

{
  lib,
  pkgs,
}:

let
  pname = "jan";
  version = "0.6.4";
  src = pkgs.fetchurl {
    url = "https://github.com/menloresearch/jan/releases/download/v${version}/Jan_${version}_amd64.AppImage";
    hash = "sha256-bMsJtu43UGJQ/ZyFsqTofym3BhT/mjvcnAV13WTXDSI=";
  };

  appimageContents = pkgs.appimageTools.extractType1 { inherit pname version src; };
in
pkgs.appimageTools.wrapType1 {
  inherit pname version src;

  extraInstallCommands = ''
    install -Dm444 ${appimageContents}/usr/share/applications/Jan.desktop $out/share/applications/jan.desktop
    substituteInPlace $out/share/applications/jan.desktop \
      --replace-fail 'Exec=Jan' 'Exec=jan'
    cp -r ${appimageContents}/usr/share/icons $out/share
  '';

  meta = {
    changelog = "https://github.com/menloresearch/jan/releases/tag/v${version}";
    description = "Jan is an open source alternative to ChatGPT that runs 100% offline on your computer";
    homepage = "https://github.com/menloresearch/jan";
    license = lib.licenses.agpl3only;
    mainProgram = "jan";
    maintainers = [ ];
    platforms = with lib.systems.inspect; patternLogicalAnd patterns.isLinux patterns.isx86_64;
  };
}

Btw the latest working nixpkg is 0.5.6: https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/by-name/ja/jan/package.nix; there's an "unstable" one https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/by-name/ja/jan/package.nix but I think these are autogenerated.

[turtton]

Yes. I helped with the most recent PR and tried using 0.6.5, encountering an issue where MCP wouldn't work. While investigating the cause in more detail, I began working on building from source.
MCP-related issues are briefly mentioned here, but no progress has been made. Given that MCP systems function correctly in other NixOS installations with other software (such as ClaudeCode), and that jan's MCP works on other Linux distributions, there must be some workaround available. I'm planning to investigate this in more detail in the future.

[turtton]

Ah, I've realized I was slightly mistaken. The rpmpc build issue can be resolved by having it fetch targets from crates.io.
However, there's still a build problem on the yarn side, and I'm continuing to work on it.
If you know what solution might work, please let me know.

turtton/nixpkgs@930cc90#diff-1f58b3c19519f8cfba4329a944029d7c7763694cb7cf478c01c429e84b5ed6de

error:

       last 25 log lines:
       > Running phase: patchPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > no configure script, doing nothing
       > Executing yarnBerryConfigHook
       > Validating consistency between /build/source/yarn.lock and /nix/store/nqq6l5i8hnsfl1gq2mnd13gadckbb51g-offline/yarn.lock
       > Validating consistency of missing-hashes.json
       > ➤ YN0000: Successfully set enableTelemetry to false
       > ➤ YN0000: Successfully set enableGlobalCache to false
       > ➤ YN0000: · Yarn 4.9.1
       > ➤ YN0000: ┌ Resolution step
       > ➤ YN0001: │ RequestError: getaddrinfo EAI_AGAIN registry.yarnpkg.com
       >     at ClientRequest.<anonymous> (/nix/store/8xbq9g1kbbhy0cwy0m88pn4l7yr3mvz4-yarn-berry-offline-4.9.1/bin/yarn:147:14258)
       >     at Object.onceWrapper (node:events:633:26)
       >     at ClientRequest.emit (node:events:530:35)
       >     at c.emit (/nix/store/8xbq9g1kbbhy0cwy0m88pn4l7yr3mvz4-yarn-berry-offline-4.9.1/bin/yarn:142:14855)
       >     at emitErrorEvent (node:_http_client:104:11)
       >     at TLSSocket.socketErrorListener (node:_http_client:518:5)
       >     at TLSSocket.emit (node:events:518:28)
       >     at emitErrorNT (node:internal/streams/destroy:170:8)
       >     at emitErrorCloseNT (node:internal/streams/destroy:129:3)
       >     at process.processTicksAndRejections (node:internal/process/task_queues:90:21)
       >     at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:120:26)
       > ➤ YN0000: └ Completed in 7s 402ms
       > ➤ YN0000: · Failed with errors in 7s 408ms