Le ven. 8 mars 2024, 17:42, Even Rouault <even.roua...@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. > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
