Andrew,
obviously this code having essentially passed through the ages since
2008, I don't remember all the details :-) I assume this was an attempt
to pick up a binary that could be run and was part of the build tree,
instead of a system gdalinfo/etc. binary, but this could likely be
simplified by assuming that the PATH is set to have the path for the
binaries of the GDAL build listed first. Running through ctest should
already ensure this. Running directly with pytest, not necessarily, but
developers are then supposed to correctly set their env (e.g with
scripts/setdevenv.sh on Unix), and CI configs should hopefully do that.
If you were to change this, it would be nice though to check that the
version reported by the utility matches the one of the Python bindings
to detect potentially mismatches.
Even
Le 06/06/2024 à 23:05, Andrew Bell via gdal-dev a écrit :
The function in the subject returns a path to a utility on which to
run a test. But in the process, it tries to run the utility itself.
This seems strange. In my case, the test itself failed, but the code
reported "Could not find {file}", which is incorrect. It also causes
the actual tests to get skipped, when they should fail.
I can fix this, but I don't understand why there's an attempt to run a
utility in order to determine its path. I would think that checking
that the file exists would be sufficient (and this already occurs),
but I'm not privy to the history.
--
Andrew Bell
andrew.bell...@gmail.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
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
