Nils Nolde <[email protected]> writes: > It's mostly about making a self-contained plugin really. It's > definitely not an option to have users install that stuff from source, > there's thing like boost, protobuf etc involved and the very latest on > Windows people will (rightfully) never even try. The Python bindings > are pre-packaged as wheels, so installation becomes trivial. In that > sense users could do it themselves potentially, but code can as well > and I'd like that for UX. And my feeling is that the extra effort for > automating that process is probably dwarfed compared to the tickets > we'd get from users who don't manage to install things into OSGeo4W > python.
Thanks, that is understandable, although I disagree about "rightfully".... >>> I know it's strongly discouraged to submit binary components to the >>> official plugin store. Also that wouldn't make much sense, some of >>> those dependencies weigh like 30 MB or more (per platform). Can >>> someone point us to a plugin that has a similar logic of pulling >>> binary libs? I'd like to avoid to leave it to the user to install >>> those dependencies, rather have it done automatically. >> And 'per platform' is going to support only a handful of platforms, >> compared to all the places where one can build qgis. > Haha true! At least it's a manylinux distribution for linuxes with > glibc 2.24 (didn't wanna go down the rabbit hole of earlier versions > with that many dependencies). 3 distros (mac 10.9, win amd64, > manylinux) would amount to well over 300 MB, of which only a third is > relevant to a single platform. And then there are other operating systems, including ones that mainsteram qgis culture hasn't heard of -- so there really needs to be a "you must first install X, Y and Z", even if there is pre-built versions for popular systems. >> It could be that I'm asking questions about the broader plugin >> architecture and portability, more than your situation. > I guess the consent is to trust binaries being executed on a user's > machine (I figured that's the reason QGIS doesn't want it). To a That would be my concern, but I'm on the paranoid side. > lesser extent maybe size. Licenses will be mostly GPL, maybe some > closed (only for the bindings and packaging, the underlying engine is > FOSS), still an ongoing discussion. I am surprised it is considered ok to have non-free software as part of a plugin. Usually in Free Software plugins are considered derived works of the project, so them including code not compatible with GPL2 seems problematic. I wasn't clear on the project's stance, but it seems to be exactly this typical norm: https://blog.qgis.org/2016/05/29/licensing-requirements-for-qgis-plugins/ (I'm just a random user and packager, not speaking with any official hats.)
signature.asc
Description: PGP signature
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
