[OPTIMIZATION] Use %LocalAppData% instead of hardcoded paths

[o3wiz]

Description of the new feature / enhancement

Winget currently installs packages to the absolute path:

C:\Users\<user_name>\AppData\Local\Microsoft\WinGet\Packages

Instead, using %LocalAppData% would improve flexibility and compatibility:

%LocalAppData%\Microsoft\WinGet\Packages

Proposed technical implementation details

No response

[Trenly]

It already does use the indirect path to LOCALAPPDATA through the KNOWNFOLDERID Shell API, and does not build an absolute path

winget-cli/src/AppInstallerCommonCore/Runtime.cpp

Lines 191 to 200 in a3cea27

	case PathName::PortablePackageUserRoot:
	result.Path = Settings::User().Get<Setting::PortablePackageUserRoot>();
	if (result.Path.empty())
	{
	result.Path = GetKnownFolderPath(FOLDERID_LocalAppData);
	result.Path /= s_PortablePackageUserRoot_Base;
	result.Path /= s_PortablePackageRoot;
	result.Path /= s_PortablePackagesDirectory;
	}
	mayBeInProfilePath = true;

winget-cli/src/AppInstallerSharedLib/Filesystem.cpp

Lines 310 to 315 in a3cea27

	std::filesystem::path GetKnownFolderPath(const KNOWNFOLDERID& id)
	{
	wil::unique_cotaskmem_string knownFolder = nullptr;
	THROW_IF_FAILED(SHGetKnownFolderPath(id, KF_FLAG_NO_ALIAS | KF_FLAG_DONT_VERIFY | KF_FLAG_NO_PACKAGE_REDIRECTION, NULL, &knownFolder));
	return knownFolder.get();
	}

[o3wiz]

@Trenly
It looks like the implementation should behave as you've described, but in practice, the absolute path still ends up being written directly into the PATH environment variable.

[Trenly]

@o3wiz - But isn't that the way it should be? Imagine the case where a package is installed with WinGet, then a user changes where %LOCALAPPDATA% points to without moving the already installed files. In that scenario, the installation would become broken and the package would be unusable until either the environment variable is reverted back, or the files are moved

[o3wiz]

@o3wiz - But isn't that the way it should be? Imagine the case where a package is installed with WinGet, then a user changes where %LOCALAPPDATA% points to without moving the already installed files. In that scenario, the installation would become broken and the package would be unusable until either the environment variable is reverted back, or the files are moved

I'm not sure that's a realistic scenario; after all, changing %LocalAppData% manually seems unusual. A more common case might be if the user changes their username, causing hardcoded paths to break.

[Trenly]

I see. . .

[ArnieGA]

@Trenly
Here's another use case example: usernames that contain a space. It affects other applications that leverage Winget, like UnigetUI, where it causes a warning about winget having to be fixed (reset). In this case in particular, an exception is always thrown in Powershell related to the user's directory in Windows.

For example:

• Username: "Firstname Lastname"
• %LocalAppData%: "C:\Windows\Firstname Lastname\AppData\Local"
• Error thrown when resetting Winget:

'C:\Users\Firstname' is not recognized as an internal or external command,
operable program or batch file.
ERROR: The process "winget.exe" not found.

It seems as if having a space in the username was not considered, or purposely left out.

[whindsaks]

PathUnExpandEnvStrings