On 12/19/2016 03:33 PM, Alessandro Pasotti wrote: > On Mon, Dec 19, 2016 at 3:26 PM, Luigi Pirelli <[email protected] > <mailto:[email protected]>> wrote: > > Hi Alessandro > > this can be radical, but has the positive effect to introduce a "best > practice" to develop plugins with external binary dependencies... I > would agree, but what else respect that plugins that now have already > binaries and were accepted? Should be modified! > > Last case from some minutes ago is this just approved plugin with a > jar included > https://github.com/enricofer/QgisODK/tree/master/pyxform/odk_validate > <https://github.com/enricofer/QgisODK/tree/master/pyxform/odk_validate> > that came from a nother external foss project. > > Because everyone have to modify it's plugin to move to qgis3 => we > could leave proposal 1) for 2.x and proposal 2) for qgis3.0 giving > time to adapt the plugin to downloading binary from external repo. > > cheers > Luigi Pirelli > > > > I've just checked on the plugins site where somebody (I believe Paolo) > wrote a policy: > > ... > does not contain architecture-dependant binaries > ...
... which in the two cases here (cython and java) shouldn't be triggered because both are architecture independent. > > > As I said, I'm in favour of a source-only policy, there are easy > technical solutions to download binaries after installation if a plugin > requires them and hosting on our plugin site binary blobs that we cannot > inspect doesn't look a good idea to me. If that doesn't sound like a good idea, I'm not sure it's better to prefer a (silent) download of "some binaries" from "somewhere" in the net. Just for reference, as far as I know, python wheels also allows uploading pre-compiled binaries to their repo. But I might also just be missing the point. Matthias _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
