Hi all.
All py grass commands in QGIS stopped working a while ago:
http://hub.qgis.org/issues/4667
now we are fixing them from the QGIS side, but apparently this is due to a change in behaviour from the GRASS side.
We at Faunalia are ready to invest to keep the plugin working, and will greatly appreciate if someone from the GRASS side could let us know when something potentially harmful for it is done, so we can fix it sooner.
In general, a better coordination between the two projects is necessary, if we want to keep the plugin working over the long term.
Thanks in advance.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Hi Paolo,
All py grass commands in QGIS stopped working a while ago:
http://hub.qgis.org/issues/4667
now we are fixing them from the QGIS side, but apparently
this is due to a change in behaviour from the GRASS side.
We at Faunalia are ready to invest to keep the plugin
working, and will greatly appreciate if someone from the
GRASS side could let us know when something potentially
harmful for it is done, so we can fix it sooner.
It seems from that bug report that you are building against grass trunk?
Please use the latest stable version (currently 6.4.1 soon to be 6.4.2)
for building the QGIS--GRASS plugin. Trunk is in active development
and will change all the time, without warning, guaranteed. The stable
branch will hopefully remain stable/backwards compatible for a long long
time, specifically so things like the qgis plugin will continue to work
with a minimum about of maintenance.
In general, a better coordination between the two projects
is necessary, if we want to keep the plugin working over the
long term.
completely agree.
- would a dedicated inter-project qgis-grass-plugin osgeo ML help?
- what are the biggest issues with it to work on right now?
Hamish
Il 17/01/2012 14:19, Hamish ha scritto:
It seems from that bug report that you are building against grass trunk?
not: 6.4.1
and will change all the time, without warning, guaranteed. The stable
branch will hopefully remain stable/backwards compatible for a long long
time, specifically so things like the qgis plugin will continue to work
with a minimum about of maintenance.
Unfortunately, this is not the case. A number of issues have arisen in the past.
completely agree.
- would a dedicated inter-project qgis-grass-plugin osgeo ML help?
not sure, don't think so
- what are the biggest issues with it to work on right now?
My main concern is that occasionally interfaces are changed, without letting us know, so we have to spot the problems after they occur, and with the large number of modules, this is painful; many errors risk to go unnoticed for long, especially among less popular packages.
All the best, and thanks.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Hamish ha scritto:
> It seems from that bug report that you are building
> against grass trunk?
Paolo wrote:
not: 6.4.1
sorry, I saw in http://hub.qgis.org/issues/4667
references to:
r.external.all.py
v.out.ogr.pg.py
qgis.v.kernel.rast.py
db.connect-login.pg.py
and just saw the 'trunk' when running 'locate' but not the source tree
it came from (qgis's).
so those are GRASS python scripts in qgis svn written by Radim which
use the GRASS python libraries. hopefully with 6.4.2 'import from grass'
will be a lot more stable, in the past few releases it was still under-
going some new development. But that still will be very new and will
probably continue to change a little.
note that grass scripts (both python and shell scripts) need to be in
the system PATH to work correctly.
> completely agree.
> - would a dedicated inter-project qgis-grass-plugin osgeo ML help?not sure, don't think so
my thinking was that many grass devs probably can not keep up with the
qgis-dev mailing list traffic, and many qgis devs probably can not keep
up with the grass-dev ML traffic. so if there was a low volume ML for
interested parties from both dev teams it would be easier to keep up
to date.
> - what are the biggest issues with it
> to work on right now?My main concern is that occasionally interfaces are
changed, without letting us know, so we have to spot the
problems after they occur, and with the large number of
modules, this is painful; many errors risk to go unnoticed
for long, especially among less popular packages.
command line interfaces should not have changed at all since GRASS 6.0.0
in March 2005. the goal has always been that any command (script) written
for GRASS 6.x will be forward-compatible with any future GRASS 6.x ver.
The C API has changed a little with time :-(, but I don't think you use
that? In the case that it does change, the module should bomb out with
a GIS_H API mismatch error.
The python API is still being developed, so no guarantees of stability
there.
it is hard to predict unintended consequences, but we do our best..
Hamish
Il 17/01/2012 14:54, Hamish ha scritto:
so those are GRASS python scripts in qgis svn written by Radim which
use the GRASS python libraries.
exactly.
my thinking was that many grass devs probably can not keep up with the
qgis-dev mailing list traffic, and many qgis devs probably can not keep
up with the grass-dev ML traffic. so if there was a low volume ML for
interested parties from both dev teams it would be easier to keep up
to date.
My fear, on the other side, is that nobody will realy subscribe to this one. I would do, who else?
command line interfaces should not have changed at all since GRASS 6.0.0
it is hard to predict unintended consequences, but we do our best..
It should not be too difficult: we need to know if the syntax of a command (as it happened e.g. for v.buffer), or if the interfaces changes.
In general, the coupling of QGIS and GRASS is not too tight, so it should be reasonably easy to predict when something can go wrong.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Hamish:
> my thinking was that many grass devs probably can not keep up with the
> qgis-dev mailing list traffic, and many qgis devs probably can not keep
> up with the grass-dev ML traffic. so if there was a low volume ML for
> interested parties from both dev teams it would be easier to keep up
> to date.
Paolo wrote:
My fear, on the other side, is that nobody will realy
subscribe to this one. I would do, who else?
well, at least I would.
> command line interfaces should not have changed at all since GRASS 6.0.0
> it is hard to predict unintended consequences, but we do our best..
It should not be too difficult: we need to know if the
syntax of a command (as it happened e.g. for v.buffer),
in that case when we switched out the modules we didn't fully realize
it was missing either until it was too late. IIRC it was "just" a debug
option that was removed? if we had noticed it in time the option would
have become a no-op which just produced a warning or error message.
(e.g. see 'r.sun lat=')
bugs happen...
Hamish
Il 18/01/2012 05:00, Hamish ha scritto:
well, at least I would.
well, me and you is not really much 
in that case when we switched out the modules we didn't fully realize
it was missing either until it was too late. IIRC it was "just" a debug
option that was removed? if we had noticed it in time the option would
have become a no-op which just produced a warning or error message.
(e.g. see 'r.sun lat=')
bugs happen...
Yes, but in other cases the changes were more obvious (change of module options).
The problem is that there is no direct connection between the two projects.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
i’ll be the 3th …
i love grass & Qt
Il giorno Jan 18, 2012, alle ore 2:44 AM, Paolo Cavallini ha scritto:
well, at least I would.
well, me and you is not really much
so those are GRASS python scripts in qgis svn written by Radim which
use the GRASS python libraries.exactly.
Since all is done with python, could there a test suite that runs automatically when the reference source in GRASS changes?
This way, the problems could be captured.
Tim wrote:
Since all is done with python,
(the parsing language doesn't really matter)
could there a test suite that runs automatically
when the reference source in GRASS changes?This way, the problems could be captured.
I'm not sure about wanting to do it automatically,
but here's a new script to play with:
https://trac.osgeo.org/grass/browser/grass-addons/tools/module_key_list.sh
it just dumps all module option and flag names to
a text file which you can later compare with `diff`.
todo: sort parameter and flags alphabetically within
a module so changing the order doesn't trigger a
false-positive interface change.
fwiw, the earlier problem of qgis being unhappy when
grass changed some out= to output= etc. was only
because qgis was trying to match the full word. it
could have still used out= successfully at run-time,
and only try to match the ^partial string at parse-
time. (qgis might have to have some logic to guard
against ambiguous duplicates in that case though)
Hamish