Package for Easier Installation

[dv-anomaly]

Below I'll outline some packaging possibilities. Bundling dependencies with container formats on Linux, and for easier distribution on Windows and Mac may require a licensing change. The feature-newgui branch is where all development for the next release is happening.

Linux

• Snap Package
• AppImage
• Flatpack
• Deb & RPM Repos

macOS

• py2app
• Homebrew

Windows

• cx_Freeze + Installer

Current Dependencies on feature-newgui Branch

• numpy
• pillow-simd
• qt5
• pyqt5
• ffmpeg 3.3

[ardeaf]

What licensing conflicts are there?

[djfun]

Mainly pyqt, which is licensed under the GPL. The other dependencies are under BSD, MIT or LGPL. Also: don't forget ffmpeg as a dependency.

[dv-anomaly]

@djfun good catch on ffmpeg, added it to the list.

[dv-anomaly]

If pyqt is the only hold up we could consider moving to PySide which has LGPL. Or dual license under GPL and MIT? Making the GPL version the one we ship containerized with dependencies.

[djfun]

so the code in the repository would be MIT and the packaged version with the dependencies GPL. I would be fine with that.

Would it be possible to give the user the option to use their own ffmpeg build if they want? Because we cannot distribute a compiled version with the libfdk_aac encoder. https://trac.ffmpeg.org/wiki/Encode/AAC

[rikai]

On OS X we can also package it within Homebrew which is a pretty popular way to get things over there.

I would also suggest that we hold off on focusing on packaging too much until we make the transition to qt5, as it would likely lessen the complication for some of the aforementioned platforms.

[dv-anomaly]

Homebrew could be an option. I don't use macOS much, but when I do that's who I get syncthing up and running :-)

Was a transition to qt5 ever decided on? Changing to qt5 would not make the dependency hell any easier, you're just swapping out a handful of libraries with another handful of newer libraries.

[dv-anomaly]

@djfun The source code for packaged version would still need to be made easily accessable. Depending on how that gets shipped on other platforms it's not necessarily straight forward such as PyInstaller which creates an auto-extracting exe, and puts the source files in automatically generated locations. So we might need to create a separate repository for it, or offer strictly as a compressed file that can be downloaded from the website.

Releasing GPL version outside of github would probably be ideal so all the innovation happens under the MIT license and we don't have to deal with pull requests that are incompatible with the MIT version. That said if you are not completely set on sticking with MIT, I'd be willing to work on a strictly GPL codebase as well.

[flexiondotorg]

I work for Canonical on Ubuntu and Snapcraft. I've been contacted by Wayne directly via Telegram who directed me at this issue. You can find the documentation for Snapcraft (the tool used to create and publish snaps) on https://snapcraft.io

Given that this project is developed using Python and Qt4 you'll be interested in the documentation for the snapcraft python plugin and you should use the desktop-qt4 helper, see the CasterSoundboard snapcraft for an example for an example of how to include a desktop helper. You'll also require a number of interfaces to be enabled, again the CasterSoundboard snap is a useful reference.

Once you've landed a snapcraft.yaml in this GitHub project you can quickly automate the commit, build (on multiple architectures) and publish to process by using https://build.snapcraft.io.

I invite you to join the Snapcraft Discourse forum. The entire Snapcraft and Snap team are present there, so if you have questions ask there :-)

[rikai]

@IamDH4 Yes, you'd be swapping out for a newer set of libraries that

1. Aren't EoL'd
2. Are more easily accessible and
3. Have better cross-platform integrations, HiDPI support and a slew of other nice-to-haves.

While perhaps not a requirement, i think it'll reduce some headaches long term.