I'm a bit stuck with how to proceed. Moving the wrapping to preFixup/postFixup is fine, but I'm not sure what using mkDerivationWith buys me.

Also, from my understanding the way forward is to use declarative wrappers, however if I use wrapQtAppsHook then I end up setting dontWrapQtApps = true and manually calling wrapProgram anyway.

Finally, I can't find a way to avoid double-wrapping the binaries (once for Python libs, once for QT). But that just seems to be the way it works at the moment.

Between the wrappers being reworked and the recent QT changes it's sometimes hard to differentiate between "new best practices" and deprecated patterns :-).

Does that look reasonable? I must admit I don't entirely understand which is the desired approach so I'm cargo culting from other derivations a little. It works though.

We can avoid the double wrapping safely by doing this instead:

add

 "\${qtWrapperArgs[@]}"

to makeWrapperArgs. That way the wrapper that buildPythonApplication creates will have all the arguments from qt's setup hook.

Also you don't need to include wrapQtAppsHook when using mkDerivationWith since it'll include it automatically.

We can avoid the double wrapping safely by doing this instead:

add

 "\${qtWrapperArgs[@]}"

to makeWrapperArgs. That way the wrapper that buildPythonApplication creates will have all the arguments from qt's setup hook.

Nifty! I was just trying to do this on another similar package but it was failing because I wasn't escaping the sigil. Thanks!

Also you don't need to include wrapQtAppsHook when using mkDerivationWith since it'll include it automatically.

Yeah, I just found some docs I hadn't seen before which explained this. Then looking at the source it's starting to make sense. The names were confusing me (eg it wasn't immediately obvious that mkDerivationWith is a QT specific thing just from its name).

Anyway, updated and it looks much cleaner now. Thanks for the pointers.