[GRASS-dev] [grass-code I][381] r.colors rules: some scripts broken

[Hamish]

[you should probably read this bottom-up, as solutions>>rhetoric.
hopefully the attached script demonstrates that there's really not much
of an issue here after all -> our ideas are not mutually exclusive]

> Hamish wrote:
> > I am happy for r.colors to evolve, and glad the rules files are now
> > finally merged into color=, but fear we will damage tons of user
> > scripts with this change.

Glynn:
> The longer it's left, the more scripts will be broken by the change. 

As long as the functionality is no longer advertised, no new scripts
should use it (or at least fewer and fewer).

> It's already been left far too long (if it was originally done in 5.3,
> it should have been changed for 6.0.0).

ok, but water under the bridge now.

GC:
> > > As there hasn't been a 6.3.0 release yet, the 6.3 API remains
> > > subject to change.
HB:
> > It is my understanding that module options are frozen for 6.x, not
> > 6.x.y.
GC:
> That would make the rate of evolution far too slow. It would
> essentially mean periods of several years where no real development
> can occur.
> 
> If that was the case, I would have left after 6.0.0 was released, and
> probably have forgotten all about GRASS by the time that 7.x was open
> for development.

ok, "frozen" was perhaps a bad choice of word. my meaning was "existing
command line options locked in for the duration". Repeating my main
concern: a user script written for GRASS 6.0.0 should still work with
GRASS 6.9.99. People can adapt to GUI changes easy enough, scripts are
not so flexible.

> AIUI, major numbers are for "total" change: 5.x introduced FP and
> null. 6.x (originally 5.7) completely changed the source directory
> structure (no src/src.contrib/src.nonGPL, no cmd/inter
> subdirectories), the build system, and the vector subsystem.

yes; as far as the user is concerned the data files may not be
compatible between major versions.
 
> Minor numbers are for incompatible changes,

That was not true for 6.0->6.2, we held that to mostly incremental
improvements. In fact I don't know of a single incompatible command line
change we did*. It would be a shame to first break our compatibility
guarantee so close to 7.0, as a little discipline on our part translates
into a lot of goodwill.

[*] outside of 1 option change in v.surf.rst? which was fixing an error

> release numbers are for bug fixes and backward-compatible
> enhancements.

right.

> IOW, analogous to the Linux kernel: 2.0/2.2/2.4/2.6 all have
> substantial differences, while all 2.6.x versions are mostly
> compatible with each other.

Linux kernel devel is not 100% relevant, but FwIW my understanding is
that the 2.6 line has diverged into a continual upgrade cycle (no plans
for an unstable 2.7 or next-gen 2.8).

 
> > Would quietly checking for the file in $GISBASE/etc/colors/, after
> > it isn't found normally, really hurt much?
> 
> Yes.
> 
> Either the argument to rules= is a filename or it isn't.

it *is* a file name. I'm just asking to quietly augment the search path.

> If it is a filename, relative filenames are relative to the current
> directory.

$GISBASE should start with a root "/" or "C:", so no problem there.

Even if Tcl does not allow full path names in the file browser, that's
not a problem as 1) I'm talking about passing options from a script, and
2) if the user was hell-bent on using rules= in the old way from the
auto-gen GUI window, they can type whatever string they want in the
options box - it's not the file browser until you click on the file
folder icon.

> If it isn't a filename, then it's an arbitrary string, the GUI can't
> offer a file browser for it.

gisprompt->old_file is a good thing- of course the "new" rules= file
option should use it. The remaining question is if the parser checks for
the existence of the file when using old_file, or if it is up to the
module to do that. If it's up to the module then we can code in a path-
search trick to keep backwards compatibility, aka no problem. And this
seems to be the case -- try the attached script from the command line
using "srtm" as the file name. It works, and is all I am asking for the
C code to do.


anyway, yet another reason to push the move to SVN and begin the 7.0
branch so these discussions become moot.



Hamish


ps- all scripts/ in 6.3 CVS are now updated to use "r.colors color="
instead of rules=.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g.testfile.sh
Type: text/x-sh
Size: 738 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070505/f981300a/g.testfile.bin