<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 8 mars 2024, 17:42, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thomas,<br>
><br>
> my number 1 requirement would be that the rewrite not cause any <br>
> backwards compatibility issues compared to today's argument handling. <br>
> I suspect many users are calling the gdal utilities through scripts <br>
> and it would be a pain to have to update those when upgrading gdal.<br>
<br>
Yes, backward compatibility is an obvious requirement. That said, it <br>
would not be fully backwards compatible in the situations where users <br>
currently misuse the official synopsis, and typically when they repeat <br>
an argument that is supposed to not be repeatable. Currently depending <br>
on the argument and utility, they might potentially get an error, or the <br>
first occurrence will be used, or the last occurrence will be used (most <br>
often this last case). With a standard argument parser, this will be <br>
rejected with an explicit error message. This is actually what triggered <br>
me to consider using a dedicated mechanism for argument parsing.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Backward compatibility for nominal cases will be tricky in some <br>
situations. For example I see that ogrinfo supports a weird syntax like <br>
"-geom=NO" that p-ranav/argparse cannot support out of the box (it <br>
supports ["-geom", "NO"], and if a dash dash alias is also declared, <br>
["--geom", "NO"] or ["--geom=NO"]). So for those hopefully rare cases, <br>
one will have to pre-process argv[] before passing to p-ranav/argparse <br>
so that is sees 2 separate argv[] values ["-geom", "NO"] instead to work <br>
properly.</blockquote></div></div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto">I hope those are not to common, so the rewrite does not become more difficult to maintain than today!</div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> a nice to have enhancement that could be added during this upgrade <br>
> (which actually could be incompatible with my previous point, although <br>
> I don't see any on the top of my head) would be to support "--config <br>
> key=value" alongside "--config key value" in order to align with e.g. <br>
> creation options.<br>
<br>
That's kind of orthogonal. We can support both with the logic: if the <br>
argv[i] value after "--config" has an equal sign in it, assume it is a <br>
key=value pair (none of our valid config options should have an equal <br>
sign in the key!). Otherwise assume argv[i] is the key and argv[i+1] is <br>
the value.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">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 🤞</div><div dir="auto"><br></div><div dir="auto">regards,</div><div dir="auto">tb</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div></div></div>