Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please remove external libs #16

Open
pcav opened this issue Apr 27, 2020 · 6 comments
Open

Please remove external libs #16

pcav opened this issue Apr 27, 2020 · 6 comments

Comments

@pcav
Copy link

pcav commented Apr 27, 2020

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
Copy link
Collaborator

situx commented Apr 28, 2020

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

  • The main dependency rdflib does not work with our plugin on Windows until a patch is included into a new release, so we are shipping a patched version.

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
Copy link
Author

pcav commented Apr 28, 2020

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
Copy link
Collaborator

situx commented Apr 28, 2020

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
Copy link
Author

pcav commented Apr 28, 2020

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
Copy link
Collaborator

situx commented Apr 28, 2020

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
Copy link
Author

pcav commented Apr 29, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants