My two cents:
Personally I see this whole sandbox thing as being more suitable for the
application as a whole and not specifically for the python plugins part. As
such, it seems to me that sandboxing would be a job better suited for the
OS that is running apps, and not for the apps themselves. This is what is
happening on mobile apps, and is also the direction new distribution
formats for linux such as snaps and flatpak are heading.
I'd be bummed if, as a plugin author, I'd be able to do less stuff with a
machine's resources than the core QGIS code. I mean the great thing about
QGIS' plugins is that you can use Python + QT + QGIS API in order to do
magical stuff. If all of a sudden plugins cannot access the filesystem, or
do web requests or access some sensor's output while core QGIS can still do
those things it would be less attractive to write plugins and to use QGIS
as a general GIS platform.
On a more practical note, sandboxing just for the Python side seems like a
ton of work in an area that is not related to the core QGIS mission and
that requires highly specialized talent.
On Mon, Oct 17, 2016 at 11:53 AM, Geo DrinX <geodr...@gmail.com> wrote:
> 2016-10-17 12:35 GMT+02:00 Nathan Woodrow <madman...@gmail.com>:
>> And Qt.
>> On Mon, Oct 17, 2016 at 8:35 PM, Nathan Woodrow <madman...@gmail.com>
>>> Yes I have read it, however we don't run on PyPy, we use CPython.
> So for you, there is no chance to implement a good python sandbox in
> at least in the short term ?
> Okay, well good to know.
> Qgis-developer mailing list
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___________________________ ___ __
Ricardo Garcia Silva
Qgis-developer mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer