It’s acceptable to use external python mobules (popular ones like scipy, numpy) if you want to contribute a script?
Or you have to be ‘purist’ by either invoking grass commands through pygrass or re-writing methods found in 3d-party modules?
N
It’s acceptable to use external python mobules (popular ones like scipy, numpy) if you want to contribute a script?
Or you have to be ‘purist’ by either invoking grass commands through pygrass or re-writing methods found in 3d-party modules?
N
Hi Nick,
you can use 3rd party Python packages/modules. numpy is even a standard GRASS dependency.
For extensions (GRASS modules) contributed to GRASS Addons it in best to just write into the code and documentation what is required (and maybe include also suggestion how to install these dependencies on different platforms).
The problem is when the module is included into trunk (i.e. the main source) then:
Small methods/functions can be copied (and modified) if you need just some limited part of 3rd party library functionality. Do not forget to put the reference to the original code and authors into the source code for further reference (and because of copyright/authorship).
License of 3rd party library should always be considered but since most of the libraries are licensed under ‘GPL 2 or higher’ (same as grass) or some more permissive licence (MIT style, new BSD, LGPL) it is usually not an issue.
I hope that other developers agree at least to certain extend. Actually, I don’t know if something like this is specified somewhere but it definitively should be.
Vaclav
On Sat, Sep 28, 2013 at 6:23 AM, Nick Ves <vesnikos@gmail.com> wrote:
It’s acceptable to use external python mobules (popular ones like scipy, numpy) if you want to contribute a script?
Or you have to be ‘purist’ by either invoking grass commands through pygrass or re-writing methods found in 3d-party modules?
N
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev