vortex: init at 2.2.0 by caniko · Pull Request #491344 · NixOS/nixpkgs

caniko · 2026-02-17T10:24:04Z

Things done

Resolves

MattSturgeon

Thanks for putting this together — this is an impressively thorough initial packaging effort. I won't review in-detail yet, let's get the high-level approach down first.

As a maintainer of the now-deprecated nexusmods-app package, I've been exploring similar work recently, and it's clear a lot of care went into handling Electron ABI alignment, native Node addons, Yarn workspaces, the NativeAOT FOMOD pipeline, etc.

That said, this derivation currently carries a substantial amount of complexity that may become unnecessary once Nexus-Mods/Vortex#19749 lands upstream.

Vortex will ship a generated-sources.json, which provides:

Fully resolved artefact URLs
Cryptographic hashes
A flattened dependency closure

Given nixpkgs has the same fixed-output / hash-pinned constraints, it would likely be preferable to:

Consume generated-sources.json via an update script
Remove fetchYarnDeps, merged lockfile logic, and lockfile rewriting
Reuse upstream dependency resolution instead of regenerating locally
Replace custom NuGet dependency handling similarly

This would significantly simplify the derivation and reduce long-term maintenance burden, while improving auditability.

I'd recommend considering a refactor along these lines once Nexus-Mods/Vortex#19749 is merged upstream. Alternatively, while this is still a draft, pinning src to that PR could allow aligning the dependency model early.

Ideally, I'd also like to minimise the required patches. It'd be best if we can land configurable build flags (etc) upstream, as necessary.

Aside: we also need to ensure files are formatted correctly to satisfy CI. This can be done by entering the nixpkgs shell and running treefmt, or alternatively nix-shell --run treefmt from the nixpkgs repo root.

MattSturgeon · 2026-02-17T17:24:21Z

I'm not convinced a NixOS module is warranted here. The functionality is essentially limited to installing the package, which is not enough justification for a module.

IIUC, URL-handler registration should already be handled by a properly defined desktop entry.

There may be some value in exposing options like dataDir, downloadsDir, or stagingDir, but I'm not sure these belong at the system level. These paths are inherently user-scoped and would likely be better handled via Home Manager or application-level configuration.

There may be some value in exposing options like...

My reason for including the module. I am open to it only being a home-manager module, but don't see the harm in it also being a NixOS module, the enduser should choose how to store their data. There could be multiple users, that use the per-user subsystem offered by Vortex, this subsystem is made for cases where Vortex is installed at the system level.

I can definitely appreciate that perspective. My concern is mainly about module scope and long-term cost/benefit.

Modules that do little beyond installing a package are typically viewed as low value vs their maintenance and evaluation overhead.

don't see the harm in it also being a NixOS module

Agreed — it's not about harm, but justification. We generally look for clear system-level behaviour before introducing a NixOS module.

this subsystem is made for cases where Vortex is installed at the system level

I'm not fully convinced that system-level installation alone warrants system-level configuration of runtime/data directories. Vortex still runs per-user even when installed system-wide. If it ran as a shared system service, that would be a stronger case for configuring its directories.

Vortex still runs per-user even when installed system-wide

I am saying the opposite; screenshot from the client for reference.

Home-manager module only renders shared mode useless on NixOS.

MattSturgeon · 2026-02-17T17:27:09Z

+
+  stripFindArgs = lib.concatStringsSep " -o " (map (p: "-name '${p}'") stripPatterns);
+in
+  stdenv.mkDerivation (finalAttrs: {


We can use

Suggested change

stdenv.mkDerivation (finalAttrs: {

stdenvNoCC.mkDerivation (finalAttrs: {

MattSturgeon · 2026-02-17T17:31:47Z

+    desktopItems = [
+      (makeDesktopItem {
+        name = "vortex";
+        desktopName = "Vortex";
+        comment = "Mod manager from Nexus Mods";
+        exec = "vortex --download %u";
+        icon = "vortex";
+        startupWMClass = "Vortex";
+        categories = ["Game"];
+        mimeTypes = ["x-scheme-handler/nxm"];
+      })
+    ];


Generally, if upstream provides or builds a sane desktop-entry, I prefer to use that (often with some postInstall patches). This is fine if our desktop entry must be significantly different or upstream doesn't build one (yet).

I'm not convinced it is correct to always exec with --download, though. Shouldn't that only be used when handling x-scheme-handler/nxm?

MattSturgeon · 2026-02-17T17:33:07Z

+      license = lib.licenses.gpl3Only;
+      maintainers = with lib.maintainers; [ caniko ];
+      mainProgram = "vortex";
+      platforms = ["x86_64-linux"];


We should expand this to more platforms; lib.platforms.linux at a minimum. Ideally, we'd also support lib.platforms.windows, but I appreciate that is hard to test and maintain in a nix package.

Maybe in separate PRs?

Let's defer discussion until later in the PR. I'd prefer to optimistically declare lib.platforms.linux at least, and then do minimal testing via nixpkgs-review-gha.

lib.platforms.windows is an idealistic stretch goal, and probably something we're unlikely to actually maintain. That's definitely out-of-scope for the initial PR.

MattSturgeon · 2026-02-17T17:34:14Z

+    meta = {
+      description = "The elegant, powerful, and open-source mod manager from Nexus Mods";
+      homepage = "https://www.nexusmods.com/about/vortex/";
+      changelog = "https://github.com/Nexus-Mods/Vortex/releases/tag/v${finalAttrs.version}";


This can use finalAttrs.src.tag (instead of v${version}), at least when src uses a tagged version.

MattSturgeon · 2026-02-17T17:38:32Z

+    ];
+
+    meta = {
+      description = "The elegant, powerful, and open-source mod manager from Nexus Mods";


As per https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#meta-attributes,

Not start with the definite or an indefinite article.

"the" is the definite article. We can't replace with "an", as that is the indefinite article.

Suggested change

description = "The elegant, powerful, and open-source mod manager from Nexus Mods";

description = "Elegant, powerful, and open-source mod manager from Nexus Mods";

We should also:

Provide factual information.

Avoid subjective language.

So

Suggested change

description = "The elegant, powerful, and open-source mod manager from Nexus Mods";

description = "Open-source mod manager from Nexus Mods";

MattSturgeon · 2026-02-17T17:39:32Z

+      homepage = "https://www.nexusmods.com/about/vortex/";
+      changelog = "https://github.com/Nexus-Mods/Vortex/releases/tag/v${finalAttrs.version}";
+      license = lib.licenses.gpl3Only;
+      maintainers = with lib.maintainers; [ caniko ];


I'd be happy to be listed as a maintainer:

Suggested change

maintainers = with lib.maintainers; [ caniko ];

maintainers = with lib.maintainers; [

caniko

MattSturgeon

];

@l0b0 may also wish to be listed.

I am all for more brains 🧠

MattSturgeon · 2026-02-17T17:40:30Z

+    src = fetchFromGitHub {
+      owner = "Nexus-Mods";
+      repo = "Vortex";
+      rev = "v${finalAttrs.version}";


Suggested change

rev = "v${finalAttrs.version}";

tag = "v${finalAttrs.version}";

We can use rev when targeting a specific commit, but when targeting a tag we should use tag.

caniko · 2026-02-17T18:17:04Z

Hello @MattSturgeon; the pleasure is mine! Thank you for the high-level perspective and for sharing your experience with the nexusmods-app package.

Regarding your suggestions:

Upstream Alignment: You’re spot on about the direction. In fact, the work in Added: Core Support for Flatpak Packaging Nexus-Mods/Vortex#19749 served as a primary inspiration for the Nix implementation presented here. I agree that shifting toward consuming generated-sources.json is the superior path for long-term maintainability and auditability within nixpkgs.
Early Dividends: Interestingly, the process of building out this version has already paid off. It helped us identify a critical bug upstream that might have otherwise gone unnoticed until later in the rollout.
Refactoring: I am fully on board with refactoring the derivation to drop the manual lockfile logic and fetchYarnDeps in favor of the upstream resolved artifacts. Aligning the dependency model now, even while that PR is in draft, makes a lot of sense to avoid double-handling the work later.
Formatting: Thank you for the reminder on treefmt. I'll ensure the files are properly formatted before the next push to satisfy the CI.

I'll begin looking into pinning src to the upstream PR branch to start the transition toward the simplified dependency model you've proposed. Minimizing patches by upstreaming build flags is also a priority I’d like to coordinate on.

Would you like me to ping you once I've pushed the initial refactor using the generated-sources.json logic for a quick look at the revised structure?

MattSturgeon · 2026-02-17T18:38:45Z

Would you like me to ping you once I've pushed the initial refactor using the generated-sources.json logic for a quick look at the revised structure?

I'm subbed to the PR, but sounds good.

Feel free to reach out on matrix too, if you want to discuss anything synchronously: @mattsturg:matrix.org

caniko · 2026-07-04T10:14:53Z

I've pushed a significant update addressing the review feedback from @MattSturgeon:

Changes

Version bump: 1.16.3 → 2.2.0

Vortex has evolved significantly upstream. The current release is v2.2.0 with a completely different build system.

Migration from yarn to pnpm

The upstream project migrated from a yarn workspace with ~50 individual extension lockfiles to a pnpm + Nx monorepo (single pnpm-lock.yaml, pnpm-workspace.yaml). This eliminates the need for the custom yarn-lock.nix merge script and fetchYarnDeps approach.

Simplified derivation

Removed: yarn-lock.nix (custom lockfile merge), native-addons.nix, fomod.nix, nuget-deps.json
Replaced with: fetchPnpmDeps + pnpmConfigHook (standard nixpkgs pnpm infrastructure)
FOMOD installer: Now a prebuilt npm dependency (@nexusmods/fomod-installer-native@0.13.2) with prebuilt Linux x64 binaries — no .NET SDK needed at build time
Build via pnpm nx run-many -t build, deploy via pnpm --filter @vortex/main deploy

Remaining work

The pnpmDeps hash is set to empty and needs to be computed:

nix-build -A vortex 2>&1 | grep 'got:'
\# Copy the hash back into pnpmDeps.hash

cc @MattSturgeon for re-review

MattSturgeon · 2026-07-04T13:14:22Z

Before I look at the diff, I'd like to make you aware of some parallel and/or related work:

You opened Include updated generated-sources.json in tagged releases Nexus-Mods/Vortex#21463 - is that still relevant? is it resolved (and can be closed) or still unresolved?
Re flatpak generated-sourced, see Update Flatpak pnpm source preparation Nexus-Mods/Vortex#23517 for the pnpm migration
A few weeks back I drafted a Vortex package here. Maybe you're interested in looking over it and/or comparing notes?

Points 2 & 3 also have some TODOs/discussion around some potential blockers in the upstream build pipeline. In particular, the flatpak generated-sources has not been ported to their pnpm build system yet, and their build system also has some "impure" and "unlocked" network steps.

Also, I don't remember whether we discussed requirements for including Vortex in Nixpkgs, yet. I'd feel a little uncomfortable about having a Nixpkgs package before the upstream Vortex team consider Vortex to be "usable" on Linux. IIUC, the Windows build of Vortex running under wine or proton will be more useful to most users still than the native linux build of Vortex, until they begin adding features like wine/proton integration (like they had in NexusMods.App), xdg-portals integration, etc.

Should we consider this a draft until then? Or is the Linux build more feature-complete than I remember? Perhaps it'd make sense to maintain the package separately from Nixpkgs for a while (in a dedicated flake)?

Even if we do land this in Nixpkgs early, we should come up with a way to inform users that Vortex's Linux version is considered pre-alpha. Maybe via meta.problems?

MattSturgeon

Most of the earlier review still stands. Here's some additional feedback on the current diff.

There are still some bigger questions to address before we can consider merging though, even once all feedback is addressed. See #491344 (comment)

MattSturgeon · 2026-07-04T13:26:09Z

+      --replace-fail \
+        'process.exit(0);' \
+        'process.exit(0);' \


MattSturgeon · 2026-07-04T13:30:34Z

+    # Wrap with electron
+    makeWrapper ${electron}/bin/electron $out/bin/vortex \
+      --add-flags $out/opt/vortex \
+      --add-flags "\''${NIXOS_OZONE_WL:+\''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations --enable-wayland-ime=true}}" \
+      --set GTK_USE_PORTAL 0 \
+      --set IGNORE_UPDATES yes


We may benefit from #487711 once merged

MattSturgeon · 2026-07-04T13:31:14Z

+      --add-flags $out/opt/vortex \
+      --add-flags "\''${NIXOS_OZONE_WL:+\''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations --enable-wayland-ime=true}}" \


Can we prefer to use --add-flag (per flag) to avoid whitespace-splitting footguns?

MattSturgeon · 2026-07-04T13:34:27Z

+    npm_config_arch = "x64";
+    npm_config_platform = "linux";


Do these two actually need to be exported env vars, or are normal shell variables fine?

MattSturgeon · 2026-07-04T13:35:23Z

+  autoPatchelfHook,
+}:
+
+stdenv.mkDerivation (finalAttrs: {


Upstream have been using clangStdenv. Does this matter?

Do we actually need a C compiler, or can we use stdenvNoCC?

MattSturgeon · 2026-07-04T13:37:49Z

+    owner = "Nexus-Mods";
+    repo = "Vortex";
+    rev = "v${finalAttrs.version}";
+    hash = "sha256-1g68wgbqb9ymlispwph9r9zk86jgq81i3zm7j5y848dh73zz0705";


error: invalid SRI hash '1g68wgbqb9ymlispwph9r9zk86jgq81i3zm7j5y848dh73zz0705', length 39 != expected length 32

MattSturgeon · 2026-07-04T13:38:06Z

+  src = fetchFromGitHub {
+    owner = "Nexus-Mods";
+    repo = "Vortex";
+    rev = "v${finalAttrs.version}";


Suggested change

rev = "v${finalAttrs.version}";

tag = "v${finalAttrs.version}";

MattSturgeon · 2026-07-04T13:38:24Z

+  pnpmDeps = fetchPnpmDeps {
+    inherit (finalAttrs) pname version src;
+    fetcherVersion = 3;
+    hash = "";


MattSturgeon · 2026-07-04T13:40:42Z

+
+  pnpmDeps = fetchPnpmDeps {
+    inherit (finalAttrs) pname version src;
+    fetcherVersion = 3;


pnpm 11 benefits from

Suggested change

fetcherVersion = 3;

fetcherVersion = 4;

See also #531657 which we may benefit from if merged

MattSturgeon · 2026-07-04T13:45:46Z

+  };
+
+  pnpmDeps = fetchPnpmDeps {
+    inherit (finalAttrs) pname version src;


We are supposed to pass fetchPnpmDeps the pnpm package we're using

We can pass it the actual package, instead of having it lookup our package from pkgs.${pname}

Suggested change

inherit (finalAttrs) pname version src;

inherit (finalAttrs) pname version src;

inherit pnpm;

pkg = finalAttrs.finalPackage

As per:

It is recommended to pin pnpm to a major version, due to regular breaking changes in the store format
The latest major version is always available under pkgs.pnpm

We should also add at the top of the file:

let pnpm = pnpm_11; in

See: https://nixos.org/manual/nixpkgs/unstable/#javascript-pnpm

caniko · 2026-07-04T18:48:52Z

@MattSturgeon thanks for the review and the pointers.

On the strategic questions:

#21463 -- still open, no response from Vortex maintainers yet. The upstream pnpm migration PR (#23517) is also still open. fetchPnpmDeps off the lockfile is a pragmatic middle ground until those land.

Your nix-package branch -- adopted it wholesale. Your duckdb-extensions FOD, font-scanner node-gyp fix, electron-builder patching, and upstream desktop entry are all better than what I had. Transplanted into pkgs/by-name/vo/vortex/ for nixpkgs layout, authorship preserved in maintainers.

Linux-readiness -- agreed. PRs in draft, will add meta.problems if we get close to merging before upstream signals the Linux build is feature-complete.

The derivation is a single commit on current master, using master's pnpm_11 (v11.9.0), electron_42-bin, pnpmBuildHook, and nodejs (v24.16.0). All 167 Nx build tasks pass. The full build will need a machine with more disk space than this sandbox, but the derivation is ready for your nixpkgs-review pass whenever you have a moment.

MattSturgeon · 2026-07-04T22:21:18Z

+    "11" = {
+      version = "11.5.1";
+      hash = "sha256-3npcG+2DAYBRg6h5l/4XIM1crvtXvoOFNaS/xKFZaVk=";
+    };


pnpm 11 is already on master, but your branch is 80064(!) commits behind

Based on MattSturgeon's derivation from MattSturgeon/Vortex@nix-package. Uses nixpkgs master infrastructure (pnpm_11 v11.9.0, electron_42-bin, pnpmBuildHook, fetchPnpmDeps fetcherVersion 4, nodejs_24 v24.16.0). Key features: - pnpm + Nx monorepo build (pnpmBuildHook + pnpmConfigHook) - duckdb-extensions as separate FOD derivation - font-scanner node-gyp rebuild in buildPhase - Upstream flatpak desktop entry (patched run.sh -> vortex) - electron-builder config patched with Nix-provided Electron - forceLegacyDeploy workaround for pnpm 11 deploy bug (NixOS#5315) - Offline deploy with metadata cache pre-population - __structuredAttrs = true, strictDeps = true - meta: linux only, factual description, MattSturgeon as co-maintainer

caniko · 2026-07-06T22:45:55Z

@MattSturgeon rebased onto current master, dropped all the backported patches. Using master's pnpm_11 (v11.9.0), electron_42-bin, pnpmBuildHook, fetcherVersion 4, nodejs v24.16.0. Single commit, just the package.nix.

Added forceLegacyDeploy: true (pnpm 11 deploy bug workaround, pnpm#5315) and a preBuild step that copies store metadata into ~/.cache/pnpm/ so pnpm deploy --offline resolves in the sandbox. All 167/167 Nx tasks pass.

caniko changed the title ~~Nexus vortex~~ vortex: init at 1.16.2 Feb 17, 2026

This was referenced Feb 17, 2026

Vortex mod manager #147228

Open

vortex: init at 1.6.14 #203404

Closed

caniko mentioned this pull request Feb 17, 2026

Added: Core Support for Flatpak Packaging Nexus-Mods/Vortex#19749

Merged

caniko force-pushed the nexus-vortex branch from e298096 to 1e07e25 Compare February 17, 2026 13:59

caniko changed the title ~~vortex: init at 1.16.2~~ vortex: init at 1.16.3 Feb 17, 2026

caniko mentioned this pull request Feb 17, 2026

[Linux] Directory picker for manual game location does not work Nexus-Mods/Vortex#20439

Open

MattSturgeon requested changes Feb 17, 2026

View reviewed changes

nixpkgs-ci Bot removed the 9.needs: reviewer This PR currently has no reviewers requested and needs attention. label Feb 17, 2026

caniko mentioned this pull request Mar 9, 2026

Include updated generated-sources.json in tagged releases Nexus-Mods/Vortex#21463

Open

MattSturgeon reviewed Jul 4, 2026

View reviewed changes

caniko marked this pull request as draft July 4, 2026 18:48

nixpkgs-ci Bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 4, 2026

MattSturgeon changed the title ~~vortex: init at 1.16.3~~ vortex: init at 2.2.0 Jul 4, 2026

MattSturgeon reviewed Jul 4, 2026

View reviewed changes

caniko force-pushed the nexus-vortex branch from eaf1878 to 9d21f2a Compare July 6, 2026 22:42

	stdenv.mkDerivation (finalAttrs: {
	stdenvNoCC.mkDerivation (finalAttrs: {

	description = "The elegant, powerful, and open-source mod manager from Nexus Mods";
	description = "Elegant, powerful, and open-source mod manager from Nexus Mods";

	description = "The elegant, powerful, and open-source mod manager from Nexus Mods";
	description = "Open-source mod manager from Nexus Mods";

	rev = "v${finalAttrs.version}";
	tag = "v${finalAttrs.version}";

		--add-flags $out/opt/vortex \
		--add-flags "\''${NIXOS_OZONE_WL:+\''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations --enable-wayland-ime=true}}" \

Uh oh!

Uh oh!

Conversation

caniko commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Things done

Resolves

Uh oh!

MattSturgeon left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

caniko Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

caniko commented Feb 17, 2026

Uh oh!

MattSturgeon commented Feb 17, 2026

Uh oh!

caniko commented Jul 4, 2026

Changes

Version bump: 1.16.3 → 2.2.0

Migration from yarn to pnpm

Simplified derivation

Remaining work

Uh oh!

MattSturgeon commented Jul 4, 2026

Uh oh!

MattSturgeon left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

caniko commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

caniko commented Feb 17, 2026 •

edited

Loading

caniko Feb 17, 2026 •

edited

Loading

caniko commented Jul 4, 2026 •

edited

Loading