nexusmods-app: 0.4.1 -> 0.6.0 #331150

MattSturgeon · 2024-07-30T19:51:32Z

meta.homepage for nexusmods-app is: Nexus-Mods/NexusMods.App
meta.changelog for nexusmods-app is: Nexus-Mods/NexusMods.App@v0.5.3 (release)
Upstream's contributing guide for package maintainers

Description of changes

The main change is updating to the latest version (0.5.3), however additional cleanup and reformatting using nixfmt (rfc166 style) has also been done.

~~This is WIP and still has a few issues to resolve (help needed):~~ Most issues are now resolved, just needs some cleanup and polish:

Ability to launch GUI
- Attempting to launch the GUI crashes with no output
- but does produce log files
- Fixed by dotnetCorePackages.fetchNupkg: override avalonia to include upstream fix #340493
  Upstream fix Fix --no-build publishing when axaml compiler is used AvaloniaUI/Avalonia#16835
Fix running the tests
- Tests fail to use the nixpkgs installed 7zip exe
  Upstream issue Tests fail when using NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR Nexus-Mods/NexusMods.App#1836
- Fixed by including patches from
  Fixed: Building NMA with System Extractor Nexus-Mods/NexusMods.App#1919
- Also needed to add _7zz to nativeCheckInputs
Patch and copy the .desktop files
- WIP: tidy up implementation
Check all dependencies are still needed (i.e. desktop-file-utils)
Check DefinedConstants is working
- Do they need to be set in testProps as well as buildProps?
nexusmods-app won't start .desktop file #318567

Things done

cc @l0b0 @corngood @NickCao @GGG-KILLER @erri120

Closes #317852
Closes #318647
Closes #329592
Closes #321405

Add a 👍 reaction to pull requests you find important.

pkgs/by-name/ne/nexusmods-app/update.bash

pkgs/by-name/ne/nexusmods-app/deps.nix

pkgs/by-name/ne/nexusmods-app/package.nix

pkgs/by-name/ne/nexusmods-app/update.bash

pkgs/by-name/ne/nexusmods-app/package.nix

SuperSandro2000 · 2024-07-31T11:42:41Z

pkgs/by-name/ne/nexusmods-app/package.nix

        touch $out
      '';
      list-tools = runCommand "${pname}-test-list-tools" { } ''
-        ${nexusmods-app}/bin/${nexusmods-app.meta.mainProgram} list-tools
+        ${nexusmods-app}/bin/${meta.mainProgram} list-tools


metaMainprogram should not really be used like this. It falls under the same category as pname. Just write the bvinary name out.

I don't mind doing this, but could you clarify the reason why this is bad practice?

From my perspective using meta.mainProgram here is DRY-er. Personally I'd go one step further and use lib.getExe, which does the same thing under the hood.

pkgs/by-name/ne/nexusmods-app/package.nix

MattSturgeon · 2024-07-31T15:39:27Z

The tests pass if I keep the patch that replaces the bundled 7zz with ours.

This implies that maybe NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR isn't being checked by the tests and they're still looking for the bundled 7zz instead of the one on the PATH.

Either that, or I'm not setting the NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR build constant correctly.

Or perhaps the wrapper PATH isn't used when running the tests?

I still can't start the GUI, but the CLI commands seem to work. --help at least prints some output.

I haven't looked into patching/copying the .desktop files yet.

pkgs/by-name/ne/nexusmods-app/package.nix

MattSturgeon · 2024-08-21T10:21:35Z

I'm able to build, and I can run CLI commands such as --help. However I cannot launch the GUI.

I get no errors on stdout/stderr, however logs are printed to ~/.local/state/NexusMods.App/Logs/nexusmods.app.main.current.log:

00:00:00.651 [FATAL] (NexusMods.App.Startup) Exception crashed the application!|Avalonia.Markup.Xaml.XamlLoadException:
  No precompiled XAML found for NexusMods.App.App, make sure to specify x:Class and include your XAML file as AvaloniaResource
   at Avalonia.Markup.Xaml.AvaloniaXamlLoader.Load(Object obj)
   at NexusMods.App.App.Initialize() in /build/source/src/NexusMods.App/App.axaml.cs:line 37
   at Avalonia.AppBuilder.SetupUnsafe()
   at Avalonia.AppBuilder.Setup()
   at Avalonia.AppBuilder.SetupWithLifetime(IApplicationLifetime lifetime)
   at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime(AppBuilder builder, String[] args, Action`1 lifetimeBuilder)
   at NexusMods.App.Startup.Main(IServiceProvider provider, String[] args) in /build/source/src/NexusMods.App/Startup.cs:line 56
00:00:00.652 [DEBUG] (Microsoft.Extensions.Hosting.Internal.Host) Hosting stopping
00:00:00.652 [INFO] (Microsoft.Hosting.Lifetime) Application is shutting down...
00:00:00.654 [INFO] (NexusMods.SingleProcess.CliServer) TCP listener was cancelled, stopping
00:00:00.657 [DEBUG] (Microsoft.Extensions.Hosting.Internal.Host) Hosting stopped

Full log: nexusmods.app.main.current.log

There's other errors in the log relating to XDG stuff, however the big issue seems to be GUI resources being missing:

No precompiled XAML found for NexusMods.App.App, make sure to specify x:Class and include your XAML file as AvaloniaResource

I guess it could relate to not using the full sln here, however 0.4.1 seems to work fine even with that change...

nixpkgs/pkgs/by-name/ne/nexusmods-app/package.nix

Lines 29 to 35 in 74b8ede

    
           # If the whole solution is published, there seems to be a race condition where 
        
           # it will sometimes publish the wrong version of a dependent assembly, for 
        
           # example: Microsoft.Extensions.Hosting.dll 6.0.0 instead of 8.0.0. 
        
           # https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/7.0/solution-level-output-no-longer-valid 
        
           # TODO: do something about this in buildDotnetModule 
        
           projectFile = "src/NexusMods.App/NexusMods.App.csproj"; 
        
           testProjectFile = "NexusMods.App.sln";

cc @corngood @erri120 @Sewer56

Sewer56 · 2024-08-21T21:47:35Z

I got some time to kill. I'm not sure about the rest yet, but I can at least try fix up NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR being borked in upstream.

Sewer56 · 2024-08-21T23:23:34Z

Nexus-Mods/NexusMods.App#1919

This should fix the 7z issue upstream.
As for the rest, I'd have to look. It's very strange; not something I've experienced before.

Sewer56 · 2024-08-21T23:26:10Z

pkgs/by-name/ne/nexusmods-app/package.nix

+    [
+      # From https://github.com/Nexus-Mods/NexusMods.App/blob/v0.5.3/src/NexusMods.App/app.pupnet.conf#L38
+      "--property:Version=${version}"
+      "--property:TieredCompilation=true"


You'll also want the ReadyToRun flag here; it improves startup times, especially in something as JIT heavy at startup as NMA.

We removed ReadyToRun because we didn't have crossgen2 support in nix before, I believe after the changes by @corngood that might've been solved though.

Added in 0205410. I'll leave this thread unresolved until we can identify if it a) works with dotnet build (I can only find it documented for dotnet publish) and b) doesn't introduce issues related to crossgen2.

See #233422

Note @GGG-KILLER previously advised against this (#318647 (comment)):

This makes it so that the code is pre-compiled to the target runtime, given that we don't add the framework's RID unless it's a self-contained build, I don't recommend setting this.

...but the nexus folks claim it has some performance benefits.

I'm not sure what is meant by "framework's RID" so I'm not in a position to make an educated decision.

Sewer56 · 2024-08-21T23:37:03Z

I think, per your own comment Nexus-Mods/NexusMods.App#1866 (comment) adding ICU might be recommended here; if it's not transitively available already.

Sewer56 · 2024-08-21T23:58:19Z

There's other errors in the log relating to XDG stuff, however the big issue seems to be GUI resources being missing:

No precompiled XAML found for NexusMods.App.App, make sure to specify x:Class and include your XAML file as AvaloniaResource

I guess it could relate to not using the full sln here, however 0.4.1 seems to work fine even with that change...

As for the cause of the issue; I'm not really sure myself.

Normally this sort of thing can happen if you build an Avalonia .NET package with trimming (Or NativeAOT, which requires trimming). If some assembly isn't correctly marked for trimming, or excluded from the 'trimmer', this sort of thing can happen.
However, I'm pretty sure no trimming is going on here; instead some build step from Avalonia might not just be kicking in.

I think instead of looking at runtime errors, it may be better to grab a log of the build time, i.e. when the following code gets executed

nixpkgs/pkgs/build-support/dotnet/build-dotnet-module/hooks/dotnet-build-hook.sh

Line 58 in 50703e0

dotnet build ${1+"$projectFile"} \

. Maybe there's something telling in the build log.

GGG-KILLER · 2024-08-22T17:01:38Z

pkgs/by-name/ne/nexusmods-app/package.nix

+  dotnetBuildFlags =
+    let
+      # From https://nexus-mods.github.io/NexusMods.App/developers/Contributing/#for-package-maintainers
+      # TODO: add DefineConstants support to buildDotnetModule


I don't feel like we need to specially add support for this when we already have a general build flag input.

From my experience it's rare to see any programs using DefineConstant to configure how they're built, usually they use MSBuild properties which is the idiomatic way to enable and disable things in the .NET world.

usually they use MSBuild properties which is the idiomatic way to enable and disable things in the .NET world.

The upstream project is still in a somewhat "experimental" state, so perhaps they'd be willing to migrate to a more idiomatic method then.

cc @Sewer56 @erri120

I'm somewhat unfamiliar with dotnet, so this is a useful insight. I'll have to go read some docs 😁

We're trying to avoid build constants in the actual App as much as possible.
They're only really being used when it's desirable for package maintainers to have slightly different default runtime behaviour. Everything else is configurable at runtime.

For instance, for AppImage & Package Manager builds we add an extra message telling users to update using the System, rather than via the App. For manual installs we don't show update dialogs on the other hand.

It is possible to assign a MSBuild property other than DefineConstants here, or something like AdditionalDefineConstants that would just append to the existing constants. However at the end of the day you'll always be making some minor change. Be it adding a few characters to the build command, dropping a file, or replacing an enum value in the source to set some default behaviour at compile time.

I meant that, usually, what projects do is have some msbuild property that then defines the constant, something like this in the .csproj:

<PropertyGroup Condition="$(UseSystemExtractor) == '1'"> <DefineConstants>$(DefineConstants);NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR</DefineConstants> </PropertyGroup>

and then when building you'd do dotnet build -c Release -p:UseSystemExtractor=1.

So I don't know if it's worth adding DefineConstants support in buildDotnetModulefor something that only one app will use most likely

Ah, I've done it myself this way before too. I'd be happy to provide a constant like this upstream if the others there wouldn't mind.

I don't think there's a need to change this now unless if there's an actual need for it, as it's been done like this already it'll just generate CI churn and problems for other packagers.

I'm just speaking on behalf of the .NET team in NixOS with relation to adding a builtin option for doing this, there's nothing inherently wrong with the way this has been done upstream, it's just not conventional so I think there's other things we can direct our effort towards.

I don't think there's a need to change this now unless if there's an actual need for it, as it's been done like this already it'll just generate CI churn and problems for other packagers.

I think it's still early enough in nexusmods-app's life that it shouldn't really be an issue for other downstream packagers.

Some of the issues @Sewer56 encountered while investigating Nexus-Mods/NexusMods.App#1919 sound like they stemmed from us explicitly passing DefineConstants on the CLI. Long-term it may be better to have custom property groups, if so.

It's certainly easier to pass many "-p:{}" flags instead of joining a list of constants together using "%3B" (escaped ";")...

But I don't want to over-blow the issue; we can work with whichever implementation upstream prefers 😀

GGG-KILLER · 2024-08-22T17:02:40Z

pkgs/by-name/ne/nexusmods-app/package.nix

+    [
+      # From https://github.com/Nexus-Mods/NexusMods.App/blob/v0.5.3/src/NexusMods.App/app.pupnet.conf#L38
+      "--property:Version=${version}"
+      "--property:TieredCompilation=true"


We removed ReadyToRun because we didn't have crossgen2 support in nix before, I believe after the changes by @corngood that might've been solved though.

GGG-KILLER · 2024-08-22T19:14:59Z

@Sewer56 I'm looking at the build logs currently, and it seems like it's processing the XAML files:

/build/source/src/NexusMods.App.UI/Controls/Spine/Buttons/Download/SpineDownloadButtonView.axaml.cs(18,13): warning CS0618: 'ReactiveUiExtensions.BindToUi<TValue, TTarget, TTValue>(IObservable<TValue>, TTarget?, Expression<Func<TTarget, TTValue?>>, object?, IBindingTypeConverter?)' is obsolete: 'This should not be used anymore. See UI Coding Conventions for more details.' [/build/source/src/NexusMods.App.UI/NexusMods.App.UI.csproj]
/build/source/src/NexusMods.App.UI/Controls/Spine/Buttons/Download/SpineDownloadButtonView.axaml.cs(31,13): warning CS0618: 'ReactiveUiExtensions.BindToUi<TValue, TTarget, TTValue>(IObservable<TValue>, TTarget?, Expression<Func<TTarget, TTValue?>>, object?, IBindingTypeConverter?)' is obsolete: 'This should not be used anymore. See UI Coding Conventions for more details.' [/build/source/src/NexusMods.App.UI/NexusMods.App.UI.csproj]
/build/source/src/NexusMods.App.UI/Controls/Spine/Buttons/Download/SpineDownloadButtonView.axaml.cs(37,13): warning CS0618: 'ReactiveUiExtensions.BindToUi<TValue, TTarget, TTValue>(IObservable<TValue>, TTarget?, Expression<Func<TTarget, TTValue?>>, object?, IBindingTypeConverter?)' is obsolete: 'This should not be used anymore. See UI Coding Conventions for more details.' [/build/source/src/NexusMods.App.UI/NexusMods.App.UI.csproj]
/build/source/src/NexusMods.App.UI/Controls/Spine/Buttons/Download/SpineDownloadButtonView.axaml.cs(42,13): warning CS0618: 'ReactiveUiExtensions.BindToUi<TValue, TTarget, TTValue>(IObservable<TValue>, TTarget?, Expression<Func<TTarget, TTValue?>>, object?, IBindingTypeConverter?)' is obsolete: 'This should not be used anymore. See UI Coding Conventions for more details.' [/build/source/src/NexusMods.App.UI/NexusMods.App.UI.csproj]

I've also found the following line in the build logs but it seems unrelated:

  dotnet "/nix/store/2919w4fqxh6yr201p30z2q2y12g4iliv-nexusmods-app-0.5.3-nuget-deps/share/nuget/packages/flatsharp.compiler/7.6.0/tools/net8.0/FlatSharp.Compiler.dll" --input "Serializers/DiskStateTreeSchema.fbs" --includes "" --output obj/Release/net8.0/ --nullable-warnings true

This is the full log if anyone would like to take a look at it: https://gist.github.com/GGG-KILLER/1cd7370246aa02b6bc27eefc694543d0

I also don't get any errors when running the program but the UI still doesn't show up:

MattSturgeon · 2024-08-22T19:35:04Z

pkgs/by-name/ne/nexusmods-app/package.nix

+
+  runtimeInputs = [
+    _7zz
+    desktop-file-utils
  ];

  runtimeDeps = [


Replying to #331150 (comment) by @Sewer56:

I think, per your own comment Nexus-Mods/NexusMods.App#1866 (comment) adding ICU might be recommended here; if it's not transitively available already.

It looks like ICU is made available at runtime on the LD_LIBRARY_PATH by buildDotnetModule:

nixpkgs/pkgs/build-support/dotnet/build-dotnet-module/default.nix

Lines 187 to 192 in 8fe18a3

makeWrapperArgs = args.makeWrapperArgs or [ ] ++ [

"--prefix"

"LD_LIBRARY_PATH"

":"

"${dotnet-sdk.icu}/lib"

];

Doesn't look like it's made available at build time though (e.g. via buildInputs or nativeBuildInputs), but that might be done elsewhere 🤔

MattSturgeon · 2024-09-11T18:10:01Z

I noticed that even when installing the package persistently (e.g. using nix-env or adding it to a nixos configuration), we still can't launch it from the desktop entry.

No logs are produced either.

Running it from a terminal works as expected.

I haven't had chance to look into this properly, and based on #318567 this may not be a new issue. I wonder if anyone has any ideas though?

gbtb · 2024-09-12T16:16:38Z

Looks like the .desktop entry that's being created is pointing to an unwrapped dotnet app.
In my case, this entry points to a path /nix/store/w0xgba2xgipw1i3hppp8ndbrw5vv0z00-nexusmods-app-0.6.0/lib/nexusmods-app/NexusMods.App .
When I checked logs with journalctl -r there is an error about missing dotnet runtime:

You must install .NET to run this application.

App: /nix/store/w0xgba2xgipw1i3hppp8ndbrw5vv0z00-nexusmods-app-0.6.0/lib/nexusmods-app/NexusMods.App
Architecture: x64
App host version: 8.0.8
.NET location: Not found

Learn more:
https://aka.ms/dotnet/app-launch-failed

Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=linux-x64&os=nixos.24.11&apphost_version=8.0.8

During bisect steps I also glanced over nexusmods-app source code and noticed that it has built-in .desktop generation functionality, that runs on app startup automatically. So it may be the case that correct desktop entry from build time is overridden with incorrect one during startup.

GGG-KILLER · 2024-09-12T16:19:57Z

In my case, this entry points to a path /nix/store/w0xgba2xgipw1i3hppp8ndbrw5vv0z00-nexusmods-app-0.6.0/lib/nexusmods-app/NexusMods.App .

It seems like it's pointing to the wrong binary, it should be pointing to the one inside /bin/.

During bisect steps I also glanced over nexusmods-app source code and noticed that it has built-in .desktop generation functionality, that runs on app startup automatically. So it may be the case that correct desktop entry from build time is overridden with incorrect one during startup.

Maybe this is another thing we'll have to patch, it's worth investigating how it detects which path it puts in the desktop entries though

MattSturgeon · 2024-09-12T16:26:47Z

So the desktop entry written in postInstall to $out/share isn't being used?

That one should be using NexusMods.App from the PATH, rather than using an absolute file path. If the desktop entry is pointing to the unwrapped exe in $out/lib, then it must be coming from somewhere else...

GGG-KILLER · 2024-09-12T16:27:46Z

So the desktop entry written in postInstall to $out/share isn't being used?

That one should be using NexusMods.App from the PATH, rather than using an absolute file path. If the desktop entry is pointing to the unwrapped exe in $out/lib, then it must be coming from somewhere else...

I believe this might be for the other desktop entries that make up the file associations. Those are the only ones written at runtime from what I remember.

MattSturgeon · 2024-09-12T16:32:35Z

I believe upstream combined both desktop entries together in one of the last few releases, so there should only be one desktop entry.

According to their packaging docs, it is our responsibility to install the desktop entry, but maybe there's an upstream bug and they're also still installing one 😕

I'll look again when I get back to my desk

gbtb · 2024-09-12T16:32:38Z

Here is the logic for creating desktop files - https://github.com/Nexus-Mods/NexusMods.App/blob/v0.6.0/src/NexusMods.CrossPlatform/ProtocolRegistration/ProtocolRegistrationLinux.cs . From the context looks like that it's meant to be used for mime handler registration.

GGG-KILLER · 2024-09-12T16:36:13Z

It seems this might be a side effect of no longer setting APPIMAGE on makeWrapper:
https://github.com/Nexus-Mods/NexusMods.App/blob/8b7f01461623cbf1f5f21f3a341971805c07acd5/src/NexusMods.CrossPlatform/Process/OSInteropLinux.cs#L41-L50

MattSturgeon · 2024-09-12T18:54:05Z

Yeah, looks like the correct desktop entry is installed to $out/share, which ends up in ~/.local/state/nix/profiles/profile/share/applications, however the app seems to install a desktop entry to ~/.local/share/applications at runtime, and this causes issues.

Setting APPIMAGE should partially resolve, in that the correct exe would be used, but according to #308324 we should usually leverage the PATH instead of specifying abslute paths into the nix store. See my comment here #331150 (comment).

That'd only be a workaround anyway, since the app shouldn't be installing any .desktop file to begin with...

The docs say this shouldn't happen when we build using INSTALLATION_METHOD_PACKAGE_MANAGER, but has had limited real-world testing so may be broken.

INSTALLATION_METHOD_PACKAGE_MANAGER: This constant will prevent the App from generating a .desktop file at runtime, and will change the update notification that notifies the user about new versions. If this constant is set, the App will tell the user to update using their package manager.

And the template that we use in postInstall does contain the mimetype association for the nxm url handler.

MattSturgeon · 2024-09-12T19:43:58Z

Ah, my mistake. The desktop entry in ~/.local/share appears to be leftover from a previous version/iteration.

Removing the file causes the new one to be used, which works correctly.

Running NexusMods.App associate-nxm appears to not install a desktop entry, which is the correct behaviour.

I don't know if we want to do any cleanup for users updating from 0.4 to 0.6, as they will have both a desktop entry and an app config that will cause issues. I can't think of a good way to do such cleanup without potentially causing other issues...

GGG-KILLER · 2024-09-12T20:14:47Z

I don't know if we want to do any cleanup for users updating from 0.4 to 0.6, as they will have both a desktop entry and an app config that will cause issues. I can't think of a good way to do such cleanup without potentially causing other issues...

Yeah, I guess this is an unfortunate side-effect of not having install/uninstall scripts. Maybe our best option would be to add a module for nexusmods-app that adds a few activation scripts.

Otherwise the best option is to just document that these manual migration steps are necessary as upstream haven't added anything to handle these version migrations on their own.

- `NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR` - `INSTALLATION_METHOD_PACKAGE_MANAGER` Backport a fix for `NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR` not applying to the tests.

I don't think it's needed anymore, now we have INSTALLATION_METHOD_PACKAGE_MANAGER

https://nexus-mods.github.io/NexusMods.App/users/SystemRequirements/#linux-dependencies

See https://nexus-mods.github.io/NexusMods.App/developers/Contributing/#for-package-maintainers

MattSturgeon · 2024-09-13T12:37:50Z

For users updating there's a few things that need to be done:

Reset all modded games to a vanilla state
- e.g. wipe steam library and reinstall
- or "purge" in the pre-upgrade version of nexusmods-app
- or NexusMods.App uninstall-app (before updating)
Wipe app config
- e.g. NexusMods.App uninstall-app
- or rm -rf ~/.local/{share,state}/NexusMods.App
Remove any dynamically installed desktop entries
- e.g. rm ~/.local/share/applications/com.nexusmods.app.desktop
- NexusMods.App uninstall-app does not do this 🙁

Details

I tested whether uninstall-app will remove dynamically installed desktop entries:

$ touch ~/.local/share/applications/com.nexusmods.app.desktop

$ NexusMods.App uninstall-app
Deleted file: /home/matt/.local/state/NexusMods.App/Logs/nexusmods.app.main.current.logDeleted file: /home/matt/.local/state/NexusMods.App/Logs/nexusmods.app.slim.current.logDeleted directory: /home/matt/.local/share/NexusMods.App/DataModel/MnemonicDB.rocksdbDeleted directory: /home/matt/.local/state/NexusMods.App/LogsDeleted directory: /home/matt/.local/share/NexusMods.App/ConfigsDeleted directory: /home/matt/.local/share/NexusMods.App/DataModelApplication uninstalled successfully⏎

$ ls ~/.local/share/applications/com.nexusmods.app.desktop
/home/matt/.local/share/applications/com.nexusmods.app.desktop

Its unfortunate that this all needs to be done, and it's made more awkward by the fact that most users won't know the app will get updated when they bump their system config, let alone that these steps are required.

Note

The help text for uninstall-app is: Uninstall the application and revert games to their original state
I believe it'd have to be run using the app version that generated the app config.

I think we need to accept that the app is still "unstable" and new versions have breaking changes. 😓

Does this mean we should be retaining old versions we've packaged to allow users to pin a version they use (pkgs.nexusmods-app-0.4.1 & pkgs.nexusmods-app-0.6.0)? Or should we simply ask users to deal with all this themselves, until things stabilize upstream? Perhaps add some user-guides to the nixos wiki...

GGG-KILLER · 2024-09-13T12:42:52Z

Does this mean we should be retaining old versions we've packaged to allow users to pin a version they use (pkgs.nexusmods-app-0.4.1 & pkgs.nexusmods-app-0.6.0)? Or should we simply ask users to deal with all this themselves, until things stabilize upstream? Perhaps add some user-guides to the nixos wiki...

Having fixed versions is unnecessary imo, if people want to fix versions they can override the package to use older versions or "vendor" the older version into their config.

MattSturgeon · 2024-09-13T12:48:22Z

Otherwise the best option is to just document that these manual migration steps are necessary as upstream haven't added anything to handle these version migrations on their own.

Where should this kinda thing be documented? Is meta.longDescription appropriate for this? Presumably wiki articles are also a good place for less formal documentation 🤔

corngood · 2024-09-17T14:43:34Z

Apologies for conflicting this. This is what I was thinking about how to deal with it:

#336824 (comment)

GGG-KILLER · 2024-09-17T19:05:34Z

Where should this kinda thing be documented? Is meta.longDescription appropriate for this? Presumably wiki articles are also a good place for less formal documentation 🤔

I honestly have no idea, maybe someone else with more knowledge can tell you.

I'd go with the NixOS Wiki personally because I don't usually read longDescription (since it's folded by default in search.nixos.org), it's easier to find when google searching and we might end up with migration steps for every single version if these aren't specific to only this version.

MattSturgeon requested review from l0b0 and GGG-KILLER July 30, 2024 19:53

ofborg bot added 11.by: package-maintainer 10.rebuild-darwin: 0 10.rebuild-linux: 1-10 labels Jul 30, 2024

corngood reviewed Jul 31, 2024

View reviewed changes

pkgs/by-name/ne/nexusmods-app/update.bash Outdated Show resolved Hide resolved

SuperSandro2000 requested changes Jul 31, 2024

View reviewed changes

MattSturgeon force-pushed the nexus-0.5.3 branch from 38ad575 to 8f105b9 Compare July 31, 2024 13:04

corngood mentioned this pull request Jul 31, 2024

treewide: format files generated by nuget-to-nix with nixfmt and make code generation of nuget-to-nix follow nixfmt rules #325053

Draft

13 tasks

MattSturgeon requested review from SuperSandro2000 and corngood July 31, 2024 14:13

MattSturgeon force-pushed the nexus-0.5.3 branch 3 times, most recently from 803f31a to d365cd6 Compare July 31, 2024 15:35

This was referenced Jul 31, 2024

Tests fail when using NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR Nexus-Mods/NexusMods.App#1836

Closed

nexusmods-app: refactor the unfree variant #331355

Merged

MattSturgeon force-pushed the nexus-0.5.3 branch from d365cd6 to a2c9f64 Compare July 31, 2024 23:42

MattSturgeon force-pushed the nexus-0.5.3 branch from a2c9f64 to 74b8ede Compare August 21, 2024 10:10

MattSturgeon commented Aug 21, 2024

View reviewed changes

pkgs/by-name/ne/nexusmods-app/package.nix Outdated Show resolved Hide resolved

Sewer56 reviewed Aug 21, 2024

View reviewed changes

MattSturgeon force-pushed the nexus-0.5.3 branch from 74b8ede to cc5e82d Compare August 22, 2024 16:44

GGG-KILLER reviewed Aug 22, 2024

View reviewed changes

MattSturgeon commented Aug 22, 2024

View reviewed changes

ofborg bot added 10.rebuild-linux: 1-10 and removed 10.rebuild-darwin: 11-100 10.rebuild-linux: 11-100 labels Sep 8, 2024

corngood mentioned this pull request Sep 8, 2024

retrospy: 6.5 -> 6.6 #338143

Merged

MattSturgeon mentioned this pull request Sep 8, 2024

dotnetCorePackages.fetchNupkg: override avalonia to include upstream fix #340493

Merged

13 tasks

MattSturgeon force-pushed the nexus-0.5.3 branch from e34f505 to 7075251 Compare September 8, 2024 15:57

github-actions bot removed the 6.topic: dotnet Language: .NET label Sep 8, 2024

MattSturgeon added 6 commits September 13, 2024 13:16

nexusmods-app: 0.4.1 -> 0.6.0

58ffac9

nexusmods-app: define new constants

efb7e29

- `NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR` - `INSTALLATION_METHOD_PACKAGE_MANAGER` Backport a fix for `NEXUSMODS_APP_USE_SYSTEM_EXTRACTOR` not applying to the tests.

nexusmods-app: set ReadyToRun

d29d22d

nexusmods-app: stop setting APPIMAGE

4c0bd4e

I don't think it's needed anymore, now we have INSTALLATION_METHOD_PACKAGE_MANAGER

nexusmods-app: add missing xdg-utils dep

f03ebb5

https://nexus-mods.github.io/NexusMods.App/users/SystemRequirements/#linux-dependencies

nexusmods-app: Install desktop entry, appstream, & icons

e75000c

See https://nexus-mods.github.io/NexusMods.App/developers/Contributing/#for-package-maintainers

MattSturgeon force-pushed the nexus-0.5.3 branch from 1087f53 to e75000c Compare September 13, 2024 12:19

	makeWrapperArgs = args.makeWrapperArgs or [ ] ++ [
	"--prefix"
	"LD_LIBRARY_PATH"
	":"
	"${dotnet-sdk.icu}/lib"
	];

nexusmods-app: 0.4.1 -> 0.6.0 #331150

Are you sure you want to change the base?

nexusmods-app: 0.4.1 -> 0.6.0 #331150

Conversation

MattSturgeon commented Jul 30, 2024 • edited Loading

Description of changes

Things done

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MattSturgeon commented Jul 31, 2024 • edited Loading

MattSturgeon commented Aug 21, 2024 • edited Loading

Sewer56 commented Aug 21, 2024 • edited Loading

Sewer56 commented Aug 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MattSturgeon Aug 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sewer56 commented Aug 21, 2024 • edited Loading

Sewer56 commented Aug 21, 2024

Choose a reason for hiding this comment

MattSturgeon Aug 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GGG-KILLER Aug 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GGG-KILLER commented Aug 22, 2024 • edited Loading

Choose a reason for hiding this comment

MattSturgeon commented Sep 11, 2024 • edited Loading

gbtb commented Sep 12, 2024 • edited Loading

GGG-KILLER commented Sep 12, 2024

MattSturgeon commented Sep 12, 2024

GGG-KILLER commented Sep 12, 2024 • edited Loading

MattSturgeon commented Sep 12, 2024 • edited Loading

gbtb commented Sep 12, 2024

GGG-KILLER commented Sep 12, 2024

MattSturgeon commented Sep 12, 2024

MattSturgeon commented Sep 12, 2024

GGG-KILLER commented Sep 12, 2024 • edited Loading

MattSturgeon commented Sep 13, 2024 • edited Loading

GGG-KILLER commented Sep 13, 2024

MattSturgeon commented Sep 13, 2024

corngood commented Sep 17, 2024 • edited Loading

GGG-KILLER commented Sep 17, 2024 • edited Loading

MattSturgeon commented Jul 30, 2024 •

edited

Loading

MattSturgeon commented Jul 31, 2024 •

edited

Loading

MattSturgeon commented Aug 21, 2024 •

edited

Loading

Sewer56 commented Aug 21, 2024 •

edited

Loading

MattSturgeon Aug 22, 2024 •

edited

Loading

Sewer56 commented Aug 21, 2024 •

edited

Loading

MattSturgeon Aug 22, 2024 •

edited

Loading

GGG-KILLER Aug 22, 2024 •

edited

Loading

GGG-KILLER commented Aug 22, 2024 •

edited

Loading

MattSturgeon commented Sep 11, 2024 •

edited

Loading

gbtb commented Sep 12, 2024 •

edited

Loading

GGG-KILLER commented Sep 12, 2024 •

edited

Loading

MattSturgeon commented Sep 12, 2024 •

edited

Loading

GGG-KILLER commented Sep 12, 2024 •

edited

Loading

MattSturgeon commented Sep 13, 2024 •

edited

Loading

corngood commented Sep 17, 2024 •

edited

Loading

GGG-KILLER commented Sep 17, 2024 •

edited

Loading