Installing datalad-gooey as non-admin user on Windows

[adswa]

The information in this issue will be public. If the support event occurred on a private channel, do not include identifying information without explicit consent!

Origin: datalad/datalad-gooey#425

It seems that the datalad-installer on Windows attempts an installation under the admin user. I have tagged @christian-monch in hopes that he might know more about it - maybe its defined in the installer that he created. I looked at the installer, specifically
https://github.com/datalad/datalad-gooey/blob/69b5f083bf74ecb2bee0dc819105dda74bda4da1/tools/installer_building/windows-installer-amd64.nsi#L31-L42
but it is not entirely clear to me why LocalAppData expands to the admin user instead of a non-privileged user.

TODO (not necessarily to be performed in this order)

• Inform OP/Add reference to this issue at origin
• Clarifying Qs asked or not needed
• Nature of the issue is understood
• Inform OP about resolution

[mih]

I agree that it would be very helpful to avoid admin requirements.

[mih]

Ping @christian-monch also here.

[adswa]

Another ping @christian-monch.

I have created myself a non-privileged account (nonadmin-adina) in the meantime, and tried an installation, and it indeed wants to write files into the administrator adina account. I think its normal Windows behavior that non-privileged users can't install anything (an exception is probably stuff from the Windows store?), but it seems weird to me that the installation is attempted under the admin user. Trying to find some documentation on this.

[adswa]

I've tried installing a few programs, and they don't touch files under an admin user regardless of whether I provided an admin password or not (Google Chrome and Firefox installed themselves fine without admin password). I checked where the files ended up, and Firefox and Google Chrome installed itself into C:\Users\nonadmin-adina\AppData\Local. 7zip.exe required an admin password and let me choose an installation location; the default was C:\Program Files\. The msi installer of Inkscape also wanted an admin password and location, and defaulted to C:\Program Files. Lightburn (I used it for laser engraving and it is also Qt5 based) also goes to this directory, and when I browsed the directory I even found Git. So maybe we should install gooey there as well?

Whatever solution we come up with, the installation experience with a non-admin account is completely broken at the moment. Even if I provide an admin password, the installer happily modifies admin files and uninstalls stuff on the admin account. The gooey, even if it gets successfully installed, is unavailable on the non-admin user's account that installed it. This renders the software unusable on non-admin accounts.

[mslw]

No experience with creating the installer either, but I looked at the github workflow and the installer building scripts. The installer is generated with nsis. FWIW I see that the script uses $LOCALAPPDATA variable, which sounds like AppData\Local. I wonder if the bundled git/git-annex installers could throw off what the current user is? But that's a wild guess, I don't really see it.

[adswa]

as the topic of datalad gooey came up again in the office hour, did your explorations lead to any insights, links, thoughts to share, @christian-monch?

[adswa]

Updating this issue with recent developments:

datalad/datalad-gooey#430 resolved the issue partially by providing a partial "gooey-only" installer that installs only the python gooey dependencies in a non-admin user location. A full installer (including git and git-annex) still requires admin privileges, as the git-annex installer requires them.

@christian-monch has found the right place in the git-annex source code to fix it, and promised a PR: datalad/git-annex#176