[QGIS-Developer] network analyst in qgis

[Greg Troxel]

Nils Nolde <nilsnolde at gmail.com> 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.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210916/9fa14ba9/attachment.sig>