Expose uninstallation options as environment variables

[marcoesters]

Description

Expose uninstallation options as environment variables for EXE installers. This is useful for when packages write into locations outside of the installation directory and outside directories associated with conda (e.g., the %USERPROFILE%\.anaconda directory). Exposing these environment variables allows for pre-uninstall scripts to clean up these directories.

Currently only implemented for EXE installers since they are the only installers that allow pre-uninstall scripts.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[lrandersson]

Looks good, should we document that these environment variables exist? Perhaps we can do this separately when the MSI work is merged because they will exist but with different names. With that being said, I wonder if we should name these options with a similar pattern as in the MSI scenario:

constructor/constructor/briefcase/pre_uninstall.bat

Line 67 in d2a6fa2

>> "%LOG%" echo OPTION_REMOVE_USER_DATA=%OPTION_REMOVE_USER_DATA%

[marcoesters]

Looks good, should we document that these environment variables exist? Perhaps we can do this separately when the MSI work is merged because they will exist but with different names. With that being said, I wonder if we should name these options with a similar pattern as in the MSI scenario:

constructor/constructor/briefcase/pre_uninstall.bat

Line 67 in d2a6fa2

>> "%LOG%" echo OPTION_REMOVE_USER_DATA=%OPTION_REMOVE_USER_DATA%

They should have the same name for simplicity. I personally prefer the UNINSTALLER_* because it shows the scope of the variables. I added them to the documentation.

[lrandersson]

Looks good, should we document that these environment variables exist? Perhaps we can do this separately when the MSI work is merged because they will exist but with different names. With that being said, I wonder if we should name these options with a similar pattern as in the MSI scenario:

constructor/constructor/briefcase/pre_uninstall.bat

Line 67 in d2a6fa2

>> "%LOG%" echo OPTION_REMOVE_USER_DATA=%OPTION_REMOVE_USER_DATA%

They should have the same name for simplicity. I personally prefer the UNINSTALLER_* because it shows the scope of the variables. I added them to the documentation.

I agree with that, unfortunately the naming pattern is part of briefcase and not something we can modify within constructor.

[marcoesters]

Looks good, should we document that these environment variables exist? Perhaps we can do this separately when the MSI work is merged because they will exist but with different names. With that being said, I wonder if we should name these options with a similar pattern as in the MSI scenario:

constructor/constructor/briefcase/pre_uninstall.bat

Line 67 in d2a6fa2

>> "%LOG%" echo OPTION_REMOVE_USER_DATA=%OPTION_REMOVE_USER_DATA%

They should have the same name for simplicity. I personally prefer the UNINSTALLER_* because it shows the scope of the variables. I added them to the documentation.

I agree with that, unfortunately the naming pattern is part of briefcase and not something we can modify within constructor.

Then we have two options: call the variables the same in NSIS as they are in briefcase, or set UNINSTALLER_REMOVE_CACHES=%OPTION_REMOVE_CACHES%. I think the latter is actually needed because of --remove-config-files:

constructor/constructor/briefcase/pre_uninstall.bat

Lines 142 to 150 in d2a6fa2

	if "%OPTION_REMOVE_CONFIG_FILES%"=="1" (
	rem User installs (.nonadmin marker exists) only remove user config files.
	rem Admin installs remove both user and system config files.
	if exist "%BASE_PATH%\.nonadmin" (
	set "UNINST_ARGS=!UNINST_ARGS! --remove-config-files=user"
	) else (
	set "UNINST_ARGS=!UNINST_ARGS! --remove-config-files=all"
	)
	)