[Qgis-developer] Plugin Dependencies

Wed Nov 4 20:56:45 PST 2015

hi

> On 26 Oct 2015, at 19:28, Alessandro Pasotti <apasotti at gmail.com> wrote:
> 
> 2015-10-26 18:16 GMT+01:00 Hugo Mercier <hugo.mercier at oslandia.com <mailto:hugo.mercier at oslandia.com>>:
> Hi Alessandro,
> 
> On 26/10/2015 17:50, Alessandro Pasotti wrote:
> 
> > Hello Hugo,
> >
> > IMHO using  setuptools and pip it's a good idea, it does support
> > download and install from several protocols (git included) out of the
> > box, it also support dependencies and keywords licence tags, I'm not
> > sure that it can support custom tags too, but it it's not so important.

We have discussed this in the past (I’ll try to find a reference in the mailing list archives) but note that using setup tools / pip has a couple of issues:

1) Expecting a compiler for cpython module compilation is unrealistic. Even if the compiler is there expecting the needed dev libs to be available is unrealistic. The simple approach to this is to bundle cpython using the approach described by Victor and use the dependency mechanism for pure python modules only. 
2) What happens when plugin A tries to install Raven==4.0 and plugin B wants to install Raven==5.0? Plugins will end up trampling over each other dependencies and breaking each other. The solution for that is to use a virtualenv per plugin and expose the QGIS libs into the virtual env. But then we have a problem (maybe its ok?) that plugins cannot depend on each other and import each other’s packages.

I must say I like the idea of having stuff installed into virtualenvs. I’m not so sure about uploading the plugins themselves to pip - I can see the attraction of that but it also adds another layer of overhead for people starting out with plugin development. 

Regards

Tim

> >
> > I guess that most of the times, a plugin would not even need to be
> > hosted by us on plugins.qgis.org <http://plugins.qgis.org/> <http://plugins.qgis.org <http://plugins.qgis.org/>> but it could
> > just be a git(hub) URI (with a big red warning to the the users that
> > they are installing software from an external repository  etc. etc.).
> 
> Exactly. That are interesting features.
> 
> >
> > I'm not sure about the support on other platforms, luckily (for me) I'm
> > deeply ignorant about other OSes but it seems that windows users often
> > have a lot of problems with installing and running python code: would
> > pip/setuptools make things easier for them?
> 
> Actually, this is the main concern I have with the current system: most
> of the Windows users get their python environment through the QGIS
> installer or osgeo4w. And if a plugin needs another dependency, it has
> to be installed by other means.
> Pip does exist for Windows and OSX and could act as a package manager
> (where Linux users are usually happy with their distro package manager)
> 
> >
> > I don't understand completely what do you mean with the other points
> > (virtualenvs and binary parts) can you elaborate?
> 
> These are just ideas for now :) I don't have a strong experience with
> these tools, so it would have to be confirmed.
> But the idea is that if QGIS plugins are built with setuptools / pip,
> then you can setup different virtualenvs with different sets of plugins
> available in them. That may be interesting when dealing with different
> user profiles or during development.
> 
> About binary parts: setuptools allows to insert compilation directives
> if a module depends on C(++) parts. I don't know if this feature could
> allow plugins with compiled parts ... the idea would be to include C(++)
> sources with the plugin and have a standard way of compiling it, so that
> it could be compiled by trusted sources on main platforms ... or by the
> user if a standard compilation environment is present.
> 
> 
> Some random thoughts:
> 
> Quite powerful... but ... the current plugin packaging has very limited requirements: it's just a zipped folder with a couple of mandatory metadata and a class interface, building a simple plugin is definitely an easy task.
> 
> I'm afraid that by using a much more complicate system (such as setuptools), would solve some problem for the (few) complex plugins and create a lot of problems and increase the barrier for the vast majority of simpler plugin authors.
> 
> We should take this into account and think carefully.
> 
> 
> -- 
> Alessandro Pasotti
> w3:   www.itopen.it <http://www.itopen.it/>_______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/qgis-developer <http://lists.osgeo.org/mailman/listinfo/qgis-developer>

Tim Sutton
QGIS Project Steering Committee Member
tim at qgis.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151105/cbf7541c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 9882 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151105/cbf7541c/attachment-0001.tiff>