<div dir="ltr">Hi<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 6:46 PM, Larry Shaffer <span dir="ltr"><<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote"><div class="">On Thu, Mar 6, 2014 at 5:18 AM, Tim Sutton <span dir="ltr"><<a href="mailto:lists@linfiniti.com" target="_blank">lists@linfiniti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi<div><br></div><div>The only gotcha to this is that different plugins might require different versions of dependencies. We also toyed around in the past with the idea of each plugin having its own virtualenv for deps and then linking in the QGIS provided site_packages dir into that virtualenv too.</div>
<div></div></div></blockquote><div><br></div></div><div>+1 for a virtualenv approach. -1 if virtualenv is *not* the basis of the implementation.<br><br>The last thing users need is to download/install a plugin just to test it out, then have it automatically muck about with their global or user Python installation.<br>
<br></div><div>I think starting with a single app-wide virtualenv backend and pip-based GUI installer/manager for all plugins and console, first, would be prudent. Then, implement per-plugin virtualenv if that goes well.<br>
<br></div><div>Wouldn't per-plugin virtualenv reek havoc in the console, where global access to plugins is often very useful?<br></div></div></div></div></div></blockquote><div><br></div><div>Yes, this was the main downside we (Martin Dobias and myself) thought of when considering this idea some time ago. But with the current situation it is also possible to have interference between plugins (e.g. if more than one plugins has a top level package called 'utils' the package which will actually get loaded may be not the expected one). One simple work around with the virtual env approach would be that we have a global plugins virtual env (as you suggested above) and a per plugin virtual env which is optional. In metadata.txt, a plugin could nominate itself to be part of the global plugins venv (and thus have access to and be accessible by other plugins, but also vulnerable to changes to package versions made by other plugins) or in a private venv (in which case it would have access only to the app site-packages). I would include core plugins in the global QGIS site-packages so that e.g. processing is always available no matter what.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>I think, as a starting point, reviewing PyCharm's simple module manager and virtualenv creator would be good for including something similar in Plugin Manager, or as an independent dialog [0].<br>
</div></div></div></div></div></blockquote><div><br></div><div>Yeah they have a neat implementation (though it is probably all done in java so no cut & paste coding for us :-( ).</div><div><br></div><div>Regards</div>
<div><br></div><div>Tim</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div><br>[0 ] <a href="http://drive.dakotacarto.com/qgis/pycharm_pymod-manager.png" target="_blank">http://drive.dakotacarto.com/qgis/pycharm_pymod-manager.png</a></div></div></div></div></div></blockquote><div><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br><br></div><div>Regards,<br>
<br></div><div>Larry<br></div><div><div class="h5"><div><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Regards</div><div><br></div><div>Tim</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 1:56 PM, Tom Kralidis <span dir="ltr"><<a href="mailto:tomkralidis@gmail.com" target="_blank">tomkralidis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Thu, 6 Mar 2014, G. Allegri wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Date: Thu, 6 Mar 2014 02:31:41 -0800<br>
From: G. Allegri <<a href="mailto:giohappy@gmail.com" target="_blank">giohappy@gmail.com</a>><br>
To: Nathan Woodrow <<a href="mailto:madmanwoo@gmail.com" target="_blank">madmanwoo@gmail.com</a>><br>
Cc: qgis-developer List <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.<u></u>org</a>><br>
Subject: Re: [Qgis-developer] Fwd: A pipinstall plugin is possible? First:<br>
What's the difference between the the Osgeo4w Shell?<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Windows doesn't ship with any version of Python. Yay Windows! So we<br>
bundle our own. I personally don't mind this so much because it's easier<br>
to control the setup if we bundle it.<br>
<br>
The main thing here is just including pip and easy_install in all the<br>
windows installs, standalone and osgeo4w. Jurgen has told me that<br>
easy_install is included in the 64 bit versions but not 32 bit versions. Is<br>
that correct Jurgen?<br>
<br>
If pip is included we can easily have plugins tell us what they need and<br>
we can install them.<br>
<br>
</blockquote>
<br>
<br>
+1, this is exactly what I was imaging.<br>
A requirements.txt for pip would be all that a dev should write.<br>
<br>
</div></blockquote>
<br>
+1, this would be great (we currently manage and bundle deps in MetaSearch<br>
as a workaround).<br>
<br>
- we would have to make sure the requirements file is standardized<br>
(others may have different / additional ones, like requirements-dev.txt,<br>
pip-requirements.txt, etc.).<br>
<br>
- for MetaSearch, the requirements.txt file never makes it to the QGIS<br>
runtime, so plugin providers would need to make sure it does<div><div><br>
<br>
______________________________<u></u>_________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-<u></u>developer</a><span><font color="#888888"><br>
</font></span></div></div></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Tim Sutton - QGIS Project Steering Committee Member<br>==============================================<br>
Please do not email me off-list with technical<br>
support questions. Using the lists will gain<br>more exposure for your issues and the knowledge<br>surrounding your issue will be shared with all.<br><br>Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
==============================================</div>
</font></span></div>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div></div></div><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Tim Sutton - QGIS Project Steering Committee Member<br>==============================================<br>Please do not email me off-list with technical<br>
support questions. Using the lists will gain<br>more exposure for your issues and the knowledge<br>surrounding your issue will be shared with all.<br><br>Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
==============================================</div>
</div></div>