[gdal-dev] Using a "standard" argument parser for command line utilities?

[thomas bonfort]

Le ven. 8 mars 2024, 17:42, Even Rouault <even.rouault at spatialys.com> a
écrit :

> Thomas,
> >
> > my number 1 requirement would be that the rewrite not cause any
> > backwards compatibility issues compared to today's argument handling.
> > I suspect many users are calling the gdal utilities through scripts
> > and it would be a pain to have to update those when upgrading gdal.
>
> Yes, backward compatibility is an obvious requirement. That said, it
> would not be fully backwards compatible in the situations where users
> currently misuse the official synopsis, and typically when they repeat
> an argument that is supposed to not be repeatable. Currently depending
> on the argument and utility, they might potentially get an error, or the
> first occurrence will be used, or the last occurrence will be used (most
> often this last case). With a standard argument parser, this will be
> rejected with an explicit error message. This is actually what triggered
> me to consider using a dedicated mechanism for argument parsing.
>

fully agree. my worry concerned e.g. the "-b <int>" case where an arg
parser handling the int conversion could have been useful, but would break
our "-b mask" current usage.


> Backward compatibility for nominal cases will be tricky in some
> situations. For example I see that ogrinfo supports a weird syntax like
> "-geom=NO" that p-ranav/argparse cannot support out of the box (it
> supports ["-geom", "NO"], and if a dash dash alias is also declared,
> ["--geom", "NO"] or ["--geom=NO"]). So for those hopefully rare cases,
> one will have to pre-process argv[] before passing to p-ranav/argparse
> so that is sees 2 separate argv[] values ["-geom", "NO"] instead to work
> properly.


I hope those are not to common, so the rewrite does not become more
difficult to maintain than today!


> >
> > a nice to have enhancement that could be added during this upgrade
> > (which actually could be incompatible with my previous point, although
> > I don't see any on the top of my head) would be to support "--config
> > key=value" alongside "--config key value" in order to align with e.g.
> > creation options.
>
> That's kind of orthogonal. We can support both with the logic: if the
> argv[i] value after "--config" has an equal sign in it, assume it is a
> key=value pair (none of our valid config options should have an equal
> sign in the key!). Otherwise assume argv[i] is the key and argv[i+1] is
> the value.
>

fully agree it is orthogonal, I was just throwing in a pain point I have
today. hopefully we don't have an occurence where the config key contains
an equal sign 🤞

regards,
tb


>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240308/18d58828/attachment.htm>