search

sparqlunicorn / sparqlunicornGoesGIS

SPARQLing Unicorn QGIS Plugin (Documentation: https://sparqlunicorn.github.io/sparqlunicornGoesGIS/)
https://plugins.qgis.org/plugins/sparqlunicorn/
GNU General Public License v2.0
27 stars 6 forks source link

Please remove external libs #16

Open pcav opened 4 years ago

pcav commented 4 years ago

It would be good to unbundle the libs. They can probably be easily installed beforehand on most Linux distro, unsure about OSX, and could be included in OSGeo4W installer.

situx commented 4 years ago

It is true, that they can be installed beforehand - this was our previous solution. However, for now we face the following issue:

Concerning the inclusion of rdflib, we talked to QGIS Developers at FOSSGIS and the concensus was that the process to get a new library included as default in QGIS just because of one plugin depending on it was unlikely. Therefore we agreed on a bundling solution.

Do you have a different opinion or are there any issues with a bundling solution from your side?

pcav commented 4 years ago

thanks for your reply. gently pushing towards upstream patches in libraries is indeed one of the aims of our policy of not including bundled libs. of course, including in osgeo4w a very specialized lib used by only one plugin is not appropriate; in this case external install is preferable. the general point is: it is true that pip install is not very easy in Windows, but once learned for one plugin it becomes easy for all others, so I believe it is a small penalty for a global improvement.

situx commented 4 years ago

In my opinion - and I think this is a matter of discussion in the QGIS community - the best way would be to define some kind of a "dependency" file within the plugin which QGIS would use to install necessary dependencies when the plugin is installed within QGIS. When bundling libraries, the burden of keeping the bundled libaries up-to-date is also on us - the developers - which is a possible cause for security vulnerabilities if the plugin is not updated frequently. Indeed not the best solution.

However, in my opinion it should also be considered that not all users will be able to install dependencies. It is more likely that users would search for the plugin, install it, notice "it does not work" and uninstall it again without reading our Github documentation of how to install the dependencies. As it also did not seem possible to generate an error message when loading the plugin on Windows (as the plugin crashes before it could produce a QMessageDialog on load) we found this to be a better way to introduce the plugin to a wider audience.

pcav commented 4 years ago

Happy you share my views. I believe we should jointly find a way to make it easier for everybody to install deps, and I agree a more formal dependency system that could guide users would also be good. Would you mind starting a discussion on qgis-dev?

situx commented 4 years ago

Even though I am interested in resolving this issue I will in the next weeks not have the time to follow up on this. However if you would like to initiate a discussion I would be happy to follow the outcome.

pcav commented 4 years ago

I'd prefer if it's a plugin author to(re)start the discussion. No hurry anyway, take your time. Thanks.