Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Built-in Support for Custom Actions #1014

Open
whatamithinking opened this issue Dec 19, 2022 · 3 comments
Open

Built-in Support for Custom Actions #1014

whatamithinking opened this issue Dec 19, 2022 · 3 comments
Labels
enhancement New features, or improvements to existing features. not quite right The idea or PR has been reviewed, but more work is needed.

Comments

@whatamithinking
Copy link

What is the problem or limitation you are having?

I need to send a web request to a web service to gracefully shut it down before I update the app

Describe the solution you'd like

Built-in support through the library for custom actions, mainly just running a powershell/batch script or some executable, instead of having to manually work with a WiX file.

Describe alternatives you've considered

Directly accessing the WiX file and trying to inject the custom actions there, but that seems like an abstraction leak

Additional context

No response

@whatamithinking whatamithinking added the enhancement New features, or improvements to existing features. label Dec 19, 2022
@freakboy3742 freakboy3742 added the not quite right The idea or PR has been reviewed, but more work is needed. label Dec 20, 2022
@freakboy3742
Copy link
Member

Thanks for the suggestion. I can definitely see the type of problem you're describing; finding a good cross-platform solution is going to be difficult.

As an immediate solution, you've already identified modifying the WiX configuration file; you could also wrap that up as a customised template that is a fork of the "official" template.

The issue I see with the idea you've proposed is that simultaneously Windows specific, while also being abstracted from the specifics of the Windows platform (i.e., WiX configuration).

The approach we've been taking so far with this type of problem is to provide a direct injection point into the generated template - e.g., the dockerfile_extra_content configuration option that was recently added for AppImage, and build_gradle_extra_content for Android. These both provide extension points into the base template (so you don't need to maintain a custom template), but they do require end-users to be comfortable with the formats they're injecting into - and on Windows that means write WiX configurations (which are... near impenetrable at the best of times).

Making a specific customization for executing a shell script or executable seems like a solution that is excessively focussed, unless:

  1. Custom actions really are the "go-to" fix that everyone includes in their WiX configurations. Unfortunately, I'm not sufficiently familiar with WiX to comment on whether this is the case.
  2. There's a reasonable interpretation of "custom actions" on other platforms. I'm not sure this is the case; Windows is the only platform that produces a true "installer"; macOS Apps, Linux AppImages and Flatpaks, and mobile apps all follow the "independent app" model, rather than the installer model.

@whatamithinking
Copy link
Author

Thanks for getting back to me. I spent some time looking through the WiX Toolset docs, but I found them pretty impenetrable. This made me concerned that anytime I wanted to add something in the future, it would be a struggle and I would end up with dirty hacks. The format of those .wxs files is pretty tough to understand, preventing quick extensions because you have to really understand all the details before you can get going.

I am instead going with Inno Setup because it has a programming language built-in for simple problems (Pascal), an easy set of hooks I can setup to run any number of powershell/batch scripts I have, it has good documentation, and web searches pull up solutions to most problems. The built-in language, Pascal, is similar enough to other languages that within a few hours I was able to accomplish everything I was looking to do. I used jinja2 templates to build the .iss file and pyinstaller to bundle everything up before passing it into the installer.

Cross-compatibility is a problem when running these hook scripts as you need a language which works on each platform without modification. Since a python interpreter is already being included in the bundle, you could potentially use that with python scripts in which case you could write all your hooks in python once and run them everywhere. You would probably need to extract to a tempdir so you could handle the pre-install hooks which have to run before the files have been copied to the target installation folder. At present, I have only figured out how to run powershell/batch scripts, which would probably have to be re-written for each OS.

The injection points you mention above seem like a bit of an abstraction leak, but it sounds like you kinda already acknowledge that. I guess there will probably always be specifics on each platform which cannot be abstracted away and have to be exposed (e.g. python and Linux vs Windows filesystems), but it would be nice if end-users did not have to muck about with the formats of the OS-specific configs and could instead work with python config objects / files and perhaps write all custom actions in pure python.

@freakboy3742
Copy link
Member

You won't get any argument from me that WiX is impenetrable. I have absolutely no love for that tool, and it's documentation is abysmal. If I could find a good replacement, I would heartily endorse converting Briefcase to use it.

I haven't come across Inno Setup before; the biggest problem I can see is that it doesn't support Windows Installer, which is one of the main reasons for using the MSI format for distribution. However, if it works for you, then it sounds like a better option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New features, or improvements to existing features. not quite right The idea or PR has been reviewed, but more work is needed.
Projects
None yet
Development

No branches or pull requests

2 participants