Package as QML module

[nephros]

Just as a PoC, here's some (untested when installed) packaging of the module as an installable.

See: https://forum.sailfishos.org/t/opal-qml-components-for-app-development/15801/32 and follow-ups for reference.

[ichthyosaurus]

Nice, thank you! I'll have to test this later...

In the end, maybe it would actually make more sense to put everything into one large module like Silica because splitting Opal into small modules adds a lot of maintenance overhead. I only split it into modules because users can then decide what to copy into their apps. If they don't have to copy anything anymore, then we could simplify this...

[nephros]

Hey, thanks for looking at this.

I agree! As the upper post sais, it's a PoC (which turned out to be relatively simple), and can/should be expanded to the other "Opals" in the end.

How about making another repo here (say opal-packaging, or qt5-qml-module-opal or whatever), add applicable modules as git submodules, and develop in this new repo to make up the One True Opal Module.

I can offer to try (no promises on quality or timeframe! ;) ) to then fill such a new repo with the necessary build files (.pro and/or CMakeLists - I don't care, I hate qmake and cmake equally!).

This can start slow, with just one or two "Opals" released as a package, and more being added later.

And I guess once we figured out how to package at all, maintenance should be minimal - if everything is done right it should just be updating the subrepos and adding a new tag.

PS: Merry Christmas!

[nephros]

That being said, deciding to publish as a module that apps can depend on does have some "psychological" maintenance burden: once you get apps to depend on such a package, updates must be handled with extra care not to break existing things with updates.

[ichthyosaurus]

How about making another repo here (say opal-packaging, or qt5-qml-module-opal or whatever), add applicable modules as git submodules, and develop in this new repo to make up the One True Opal Module.

Good idea! I'm very low on free time right now so it'll be some time though...

This can start slow, with just one or two "Opals" released as a package, and more being added later.
And I guess once we figured out how to package at all, maintenance should be minimal - if everything is done right it should just be updating the subrepos and adding a new tag.

Sounds like a plan :)

I can offer to try (no promises on quality or timeframe! ;) ) to then fill such a new repo with the necessary build files (.pro and/or CMakeLists - I don't care, I hate qmake and cmake equally!).

Thank you, that would be great :). If you want you can experiment a bit with it already, I'm especially unsure about how to build compiled plugins. The SFPM module would be a candidate here... I'm also working on a Python backend in the local storage module. Do you have an idea how that could be installed?

That being said, deciding to publish as a module that apps can depend on does have some "psychological" maintenance burden: once you get apps to depend on such a package, updates must be handled with extra care not to break existing things with updates.

True. I'm already doing my best to follow semantic versioning for each individual module but with more users and Opal as a system package we'd need a clear deprecation path etc.

PS: Merry Christmas!

and a happy new year! :)