ADR and Implementation of New Default App Locations

[Sewer56]

Contest / Problem Statement

The App currently stores its files in the same folder as the application ({EntryFolder}).

This approach has issues with certain packaging formats and installers. For example, when the application is run from
an .AppImage, the EntryFolder becomes read-only, and our application fails to run.

We need to identify alternative storage locations that are both accessible and writable, regardless of how the
application is deployed or executed.

About The Document

This document (WIP ADR) presents us with existing options as to where we could potentially store our content, including some of the benefits and drawbacks for each location.

It also introduces a potential new problem that may arise should we decide to switch to a new user data location.

Feedback Requested

This is intentionally submitted as a draft PR in request for feedback.

More specifically, I request that everyone reads this, and forms their own preference/opinion on the subject matter ahead of time, as it is probably for the best that we discuss this (on call) as a team down the road.

If you have any other suggestions, fixes, etc. feel free to comment or even amend this PR directly (no force pushes over other people's stuff, let's be civilized here !!).

[Al12rs]

So one of the biggest complaints people had with Vortex when it first came out was the fact that it put its files in Appdata by default and there was no way to avoid that.
You could move out some things but people weren't happy with it.

From MO2 side as well, being able to set custom locations and supporting Portable installations was something very important for a lot of users.

Knowing this I think it's important that whatever solution we come up with for the default can be completely customized and overruled by users. In particular choosing a default location on C: drive for everything might incur into drive capacity issues.

Ideally during installation or first setup the user would be able to choose whether to create a portable instance or a normal instance. A portable instance would keep all files inside the installation folder, which would need to be write enabled. The user would still need to be able to change the locations for modfile backups etc, as those can take up hundreds of GBs and they might want to put the FileStore of different games on different drives (e.g. most game mods on NVME SSD for performance, but not the Skyrim 500GB setup).

Could we get away with having the user configure this on first startup, so we don't have to choose the default ourselves?
I imagine for a lot of people Appdata could be fine for the small stuff (our sqlite database and a few config files), but they probably want to put all the big stuff in some secondary drive.

[Sewer56]

Knowing this I think it's important that whatever solution we come up with for the default can be completely customized and overruled by users.

Note that this is already possible today 😉, I did it with some config work a while back. This ADR specifically focuses on what we should suggest to the user as a default location, rather than anything else.

As another point of note, our DataModel also supports (or used to support last I checked) having multiple archive locations; i.e. multiple places where archives are stored. This worked at the reader side, but at the writer site, there was currently not yet a mechanism to configure where new archives go. I'm not sure if the situation on that changed.

Ideally during installation or first setup the user would be able to choose whether to create a portable instance or a normal instance

Could we get away with having the user configure this on first startup, so we don't have to choose the default ourselves?

That's actually a great piece of feedback, ultimately it would require some UX designs from @captainsandypants down the road. I've also had a lot of users who have historically modified their packages path in my own solutions, and/or used portable mode.

Regarding the point of when this configuration is set, it would have to be at runtime. It's not really possible to have custom install logic for every single packaging format we should strive to support and even if we could; that would be a lot of repeated work to get set up for every single packaging format.

---

Anyway, lemme add a footnote to the ADR regarding these things.

I also need to add a sub-section regarding out non-DataStore config location (AppConfig.json), as that can't live within the app folder either.

[Sewer56]

Updated with some additional potential discussion topics regarding UX and information regarding running the app 'portably'.

[halgari]

I think it's important to note that the reason people want portable modes is often tied to the inflexability of the app in other areas. Having to have instances for MO2, Vortex treating mods as only installable once for all loadouts, etc. Solving these issues removes a lot of the need for a truely portable app. Clearly we'll always want some sort of protable system for testing and development, but I'm not sure it's a feature that we have to ship with the MVP

[erri120]

I think it's important to note that the reason people want portable modes is often tied to the inflexability of the app in other areas. Having to have instances for MO2, Vortex treating mods as only installable once for all loadouts, etc. Solving these issues removes a lot of the need for a truely portable app. Clearly we'll always want some sort of protable system for testing and development, but I'm not sure it's a feature that we have to ship with the MVP

Our loadout system is much more advanced. Once we have a proper settings system, there won't be a need to have multiple instances of the App, since you'd be able to change per-loadout locations.

[erri120]

In my opinion, we should make use of all available XDG_* user base directories (Specs, Arch Wiki) on Linux. These are also easy to access with the correct Flatpak Permissions. I put emphasis on using all available directories because there is a difference between the config, cache, data, state, and runtime directories. Our datastore would likely go into the config directory, while big mod data should go into the data directory.

On Windows, we can just stick to the local application data folder (details). The difference between ApplicationData and LocalApplicationData is that the former can be used by a roaming user, meaning the contents will be uploaded to a server. The latter is local to the machine.

Regardless of platform, I believe we should add these requirements as well:

• Don't use system directories, all data should be local to the current user.
• Only have one instance installed of the app (no "portable mode", no "multi instances").
• Allow the user to change directories on a per-loadout and/or game basis.

[Al12rs]

I agree with LocalAppdata as the default location in windows for things that shouldn't balloon in size.

If we put something that could potentially become hundreds of GBs in Appdata by default, without explicitly asking the users we will get a lot of complaints, even if it is possible to move the folder after the fact, simply because people will not know that it can be changed or how (even if it is just there staring at them in settings).

So in my opinion we should explicitly ask the user on first setup where to put the heavy stuff, to avoid the user complaints, while the smaller things like the database can be put in the default location.

[Sewer56]

I undrafted this by accident, oops. Please ignore.

[codecov]

Codecov Report

Merging #783 (b580f43) into main (75e7bf5) will decrease coverage by 0.21%.
The diff coverage is 34.54%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #783      +/-   ##
==========================================
- Coverage   63.01%   62.81%   -0.21%     
==========================================
  Files         586      586              
  Lines       18125    18201      +76     
  Branches     1277     1287      +10     
==========================================
+ Hits        11422    11433      +11     
- Misses       6361     6422      +61     
- Partials      342      346       +4     

Flag	Coverage Δ
Linux	62.09% <31.81%> (-0.20%)	⬇️
Windows	61.98% <31.81%> (-0.20%)	⬇️
clean_environment_tests	62.79% <34.54%> (-0.21%)	⬇️
networking_tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
.../NexusMods.FileExtractor/IFileExtractorSettings.cs	66.66% <66.66%> (-20.84%)	⬇️
src/NexusMods.App/AppConfig.cs	72.58% <47.82%> (-7.86%)	⬇️
src/NexusMods.DataModel/IDataModelSettings.cs	60.86% <54.83%> (-15.14%)	⬇️
src/NexusMods.App/Program.cs	0.00% <0.00%> (ø)

... and 8 files with indirect coverage changes

[codecov-commenter]

Codecov Report

Merging #783 (3cb58d8) into main (75e7bf5) will decrease coverage by 0.85%.
Report is 1 commits behind head on main.
The diff coverage is 34.54%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #783      +/-   ##
==========================================
- Coverage   63.01%   62.17%   -0.85%     
==========================================
  Files         586      594       +8     
  Lines       18125    18656     +531     
  Branches     1277     1334      +57     
==========================================
+ Hits        11422    11599     +177     
- Misses       6361     6708     +347     
- Partials      342      349       +7     

Flag	Coverage Δ
Linux	61.34% <31.81%> (-0.95%)	⬇️
Windows	61.39% <31.81%> (-0.78%)	⬇️
clean_environment_tests	62.15% <34.54%> (-0.85%)	⬇️
network_tests	?
networking_tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
.../NexusMods.FileExtractor/IFileExtractorSettings.cs	66.66% <66.66%> (-20.84%)	⬇️
src/NexusMods.App/AppConfig.cs	72.58% <47.82%> (-7.86%)	⬇️
src/NexusMods.DataModel/IDataModelSettings.cs	60.86% <54.83%> (-15.14%)	⬇️
src/NexusMods.App/Program.cs	0.00% <0.00%> (ø)

... and 61 files with indirect coverage changes