[Qgis-developer] Fwd: A pipinstall plugin is possible? First: What's the difference between the the Osgeo4w Shell?

[Tim Sutton]

Hi


On Thu, Mar 6, 2014 at 6:46 PM, Larry Shaffer <larrys at dakotacarto.com>wrote:

> Hi,
>
> On Thu, Mar 6, 2014 at 5:18 AM, Tim Sutton <lists at linfiniti.com> wrote:
>
>> Hi
>>
>> 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.
>>
>
> +1 for a virtualenv approach. -1 if virtualenv is *not* the basis of the
> implementation.
>
> 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.
>
> 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.
>
> Wouldn't per-plugin virtualenv reek havoc in the console, where global
> access to plugins is often very useful?
>

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.


>
> 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].
>

Yeah they have a neat implementation (though it is probably all done in
java so no cut  & paste coding for us :-( ).

Regards

Tim


>
> [0 ] http://drive.dakotacarto.com/qgis/pycharm_pymod-manager.png
>



>
>
> Regards,
>
> Larry
>
>
>
>> Regards
>>
>> Tim
>>
>>
>> On Thu, Mar 6, 2014 at 1:56 PM, Tom Kralidis <tomkralidis at gmail.com>wrote:
>>
>>>
>>>
>>> On Thu, 6 Mar 2014, G. Allegri wrote:
>>>
>>>  Date: Thu, 6 Mar 2014 02:31:41 -0800
>>>> From: G. Allegri <giohappy at gmail.com>
>>>> To: Nathan Woodrow <madmanwoo at gmail.com>
>>>> Cc: qgis-developer List <qgis-developer at lists.osgeo.org>
>>>> Subject: Re: [Qgis-developer] Fwd: A pipinstall plugin is possible?
>>>> First:
>>>>     What's the difference between the the Osgeo4w Shell?
>>>>
>>>>
>>>>
>>>>> Windows doesn't ship with any version of Python. Yay Windows!  So we
>>>>> bundle our own.  I personally don't mind this so much because it's
>>>>> easier
>>>>> to control the setup if we bundle it.
>>>>>
>>>>> The main thing here is just including pip and easy_install in all the
>>>>> windows installs, standalone and osgeo4w.  Jurgen has told me that
>>>>> easy_install is included in the 64 bit versions but not 32 bit
>>>>> versions. Is
>>>>> that correct Jurgen?
>>>>>
>>>>> If pip is included we can easily have plugins tell us what they need
>>>>> and
>>>>> we can install them.
>>>>>
>>>>>
>>>>
>>>> +1, this is exactly what I was imaging.
>>>> A requirements.txt for pip would be all that a dev should write.
>>>>
>>>>
>>> +1, this would be great (we currently manage and bundle deps in
>>> MetaSearch
>>> as a workaround).
>>>
>>> - we would have to make sure the requirements file is standardized
>>>   (others may have different / additional ones, like
>>> requirements-dev.txt,
>>>   pip-requirements.txt, etc.).
>>>
>>> - for MetaSearch, the requirements.txt file never makes it to the QGIS
>>>   runtime, so plugin providers would need to make sure it does
>>>
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>>
>> --
>> Tim Sutton - QGIS Project Steering Committee Member
>> ==============================================
>> Please do not email me off-list with technical
>> support questions. Using the lists will gain
>> more exposure for your issues and the knowledge
>> surrounding your issue will be shared with all.
>>
>> Irc: timlinux on #qgis at freenode.net
>> ==============================================
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>


-- 
Tim Sutton - QGIS Project Steering Committee Member
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net
==============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140306/748b5e12/attachment.html>