Variable expansion/support for Manifest InstallLocation?

[byjrack]

So I know using commandline -l or --override and %LOCALAPPDATA% gets me what I need, but trying to include a non-admin install option in the manifest itself.

I can't track down any documentation on using runtime variables in the manifest itself. Only one that jumps out a lot is "<INSTALLPATH>" which I have to assume is tied to --location arg. If I add unconventional locations like Temp or I tried <LOCALAPPDATA> for fun It ends up in %LOCALAPPDATA%\Programs which is great, but I don't know "why" it did. I don't have a defaultInstallRoot configured so seems like some logic in winget itself.

I feel like this would be a common need and documented somewhere, but can't for the life of me track down the convention for the manifest for declaring %LOCALAPPDATA% paths (root, Programs, etc) in the manifest itself. If the item is marked Portable I believe it will get put into /Packages so that might be an option, but again feels like another workaround. 💯 it would be easier if the installer had a machine wide / current user install toggle, but in the case I am working on there isn't. I would think that winget might have some helpers for architecture program files as well, but it may push that back on the installer which I get. I can see the environment variables are used liberally in the codebase, but seems to be all internal and not usable by consumers.

[florelis]

(Edited your post so that <INSTALLPATH> and <LCOALAPPDATA> show correctly)

The manifest entry for InstallLocation is not exactly meant to specify where a package should install. Rather, it is meant to let winget know how to tell the installer where to install. Then, when you use the --location argument, we pass that to the installer. So, for example, if in a manifest you set InstallLocation: /installTo <INSTALLPATH>, then if you call winget with winget install [your package] --location C:\Install\Here, we would ultimately pass to the installer the arguments /installTo C:\Install\Here

You can see it documented at https://github.com/microsoft/winget-pkgs/blob/master/doc/manifest/schema/1.0.0/installer.md#installlocation (you need to expand the text)

There's also a token you can use in the manifest for the installer's log location, but I think that's the most support there is for any kind of runtime expansion of values in the manifest.

This probably wouldn't fly in the winget-pkgs repo but in case you're doing this for a private manifest, I think you could specify an install location using the Custom flags. That is a string value with arguments that you pass directly to the installer. So if you know how to tell the specific installer where to install, you can add that as custom arguments, and winget will pass it directly to the installer. You may be able to add env variables in this string and maybe it will work (never tried, so not sure)
https://github.com/microsoft/winget-pkgs/blob/master/doc/manifest/schema/1.0.0/installer.md#custom

If you don't pass the --location argument to winget, then it doesn't matter what you put in the InstallLocation field, it's just not used.

[byjrack]

Yeah -l and --override with the installers path override work perfectly fine. I was trying to reduce some of the docs and manual process for users for products where the installer doesn't have that only user vs machine toggle. Everything goes to PF via an assumed UAC which our users can't complete.

The Custom manifest switch has the same issue as InstallLocation. "%" is an invalid token so the environment variable can't be passed to the installer from the manifest and only from command line. That's why I was hunting around for escape characters or replacements that could be used in manifest.

I had hoped it was just inept document searching, but it looks like it just isn't in the cards. The command line args will need to work until work upstream with the install maintainers is worked out. Than it may just work or I can target the toggle without needing a variable expansion.

[florelis]

"%" is an invalid token

What error do you get? I don't remember any restriction like that in the manifest. It may be a restriction on YAML files in general, in which case maybe quoting the string may help. I.e., instead of Custom: --installTo %localappdata% do Custom: '--installTo %localappdata%'

[byjrack]

So single quote definitely helped with parsing in winget validate. I haven't banged on the --location known good much to try and compare the package logs, but just what I collected thus far as examples. Nor have I dug into the YamelParser.cpp to better understand that unhandled exception.

Manifest InstallerSwitches	Result
InstallLocation: %LOCALAPPDATA%\Git	[YAML:Scanner] while scanning for the next token [line 28; col 22] found character that cannot start any token [line 28; col 22]
InstallLocation: "%LOCALAPPDATA%\Git"	[YAML:Scanner] while parsing a quoted scalar [line 28; col 22] found unknown escape character [line 28; col 37]
InstallLocation: '%LOCALAPPDATA%\Git'	Passes validation, but does not make it/is not interpreted by the installer
Custom: '/DIR=%LOCALAPPDATA%\Git'	Passes validation, but does not make it/is not interpreted by the installer
Custom: '--installTo %LOCALAPPDATA\Git'	D:a_work\1\s\external\pkg\src\AppInstallerCommonCore\Manifest\YamlParser.cpp(477)\WindowsPackageManager.dll!00007FFABA4BF2E3: (caller: 00007FFABA44713B) Exception(1) tid(274) 80070150 The specified operation is not supported on a directory. Msg:[Subdirectory not supported in manifest path]
Custom: '--installTo "%LOCALAPPDATA%\Git"'	D:a_work\1\s\external\pkg\src\AppInstallerCommonCore\Manifest\YamlParser.cpp(477)\WindowsPackageManager.dll!00007FFABA4BF2E3: (caller: 00007FFABA44713B) Exception(1) tid(274) 80070150 The specified operation is not supported on a directory. Msg:[Subdirectory not supported in manifest path]

[florelis]

InstallLocation: '%LOCALAPPDATA%\Git' Passes validation, but does not make it/is not interpreted by the installer

This is expected. The InstallLocation is not passed to the installer unless you call winget with --location.

Custom: '/DIR=%LOCALAPPDATA%\Git' Passes validation, but does not make it/is not interpreted by the installer

The winget logs should tell you what arguments are passed to the installer. You can use that to discern whether it's making it to the installer and not working, or not making it in the first place.

Custom: '--installTo %LOCALAPPDATA\Git'

To be clear, the --installTo was just a thing I made up as an example. I doubt that's what is called in the actual installer. The /DIR= one is probably what you want (depending on the installer).

Everything goes to PF via an assumed UAC which our users can't complete.

I want to point out that even if you can get the installer to write to LocalAppData, it is no guarantee that you won't get the UAC. It could be that the installer just always runs elevated, or that it also needs to write to HKLM. Before trying to figure out how to do it with winget, I would recommend manually downloading the installer and running it directly with the arguments you want, to be sure it could potentially work with winget.

[byjrack]

Yup 100% and that is how I have moved onto winget. I have the installer working as expected called manually all as unprivileged user.

What I was seeing is if I could translate those into a manifest entry versus having to provide additional command lines. Yeah I was including InstallLocation in InstallSwitches as a manifest entry as the goal was to not require a custom commandline to winget in this case. My gut is when I pass LOCALAPPDATA on the winget call the expansion happens there while if I do it in manifest the tokenname is sent to Inno which can't process it and falls back to whatever installdir logic it has. Good call to check the log between the working --location and Custom: /DIR in manifest to confirm what the difference is.