[QGIS-Developer] network analyst in qgis

[Nils Nolde]

On 16.09.21 14:59, Greg Troxel wrote:
> Nils Nolde <nilsnolde at gmail.com> writes:
>
> That all sounds like great progress.
Thanks Greg:)
>
> Speaking as a packager for systems that are somewhat unusual:
>
>> solvers, that's above our heads. For everything we need a performant
>> routing engine, so we have to include several third-party FOSS
>> projects for routing & solving, those dependencies are unfortunately
>> all binary. So after the (hopefully encouraging) announcement, my
>> question:
> I do not understand how depending on Free Software projects maintained
> by others leads to "binary dependencies".  Can these really not be built
> from source?  Do you just mean "on the system that uses the plugin, a
> bunch of other packages (and presumably their python bindings?) must be
> installed?  Is this just about making a self-contained plugin for
> Windows where expecting qgis users to manage other code is wishful
> thinking?
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.
>> 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.
>
>> Are there other recommendations to handle this situation? I guess at
>> the very least the user should agree to download those binaries. Since
>> we have to download 4 different libraries, do you think the user
>> should consent to each one individually (the routing engines are
>> crucial, but location/allocation & VRP not really)?
> Is the consent about license, about trusting the code with one's data
> (since it runs in user context), about the space, or something else?
>
> 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 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.
>
> Greg