Plugin mechanism for installer backends

[mhsmith]

Checklist

• [x] I added a descriptive title
• [x] I searched open requests and couldn't find a duplicate

What is the idea?

This was first mentioned in https://github.com/conda/constructor/issues/646#issuecomment-1446643901, in the context of a potential Inno Setup backend to replace NSIS:

Ideally, if you ask me, I would envision something like constructor offering some kind of plugin mechanism so users can use other "installer backends", and then you could maintain your own plugin facilitating that. Given enough time and if it gets a lot of traction, such a plugin could be "absorbed" in constructor itself. But of course, that plugin system does not exist right now so I might be dreaming a bit too much :D

It also came up more recently in discussions about using Briefcase as a backend on Windows.

Why is this needed?

It would allow backends to be developed and maintained separately from the core Constructor project.

However, there would also be a cost to developing and maintaining the plugin system itself. So once the Constructor team has decided how they want to replace NSIS, it might make sense to skip the plugin idea, and implement the new backend directly in Constructor. This is especially true if all the people involved will be working closely with each other, in which case the decoupling provided by a plugin system might not be worth the effort.

[marcoesters]

If a plug-in system ought to support multiple installer backends, what is the consequence for the unified installation script (#968)? Would that mean that the script has to be independent from the backend?

[mhsmith]

Yes, I guess it would. And each backend would be responsible for providing whatever infrastructure is necessary to run the script.

As you might guess from my previous comment, I'm not sure whether a plugin system is actually worth the effort, but it was mentioned in our last meeting as something we should consider.