[gdal-dev] Requiring numpy for the Python bindings

[Greg Troxel]

Laurențiu Nicola via gdal-dev <gdal-dev at lists.osgeo.org> writes:

> On Wed, Dec 6, 2023, at 16:23, Greg Troxel via gdal-dev wrote:
>> Keeping rust going has been an ongoing source of work and problems.
>> This is partly because of not having a reasonable bootstrap story from
>> C/C++, and mostly because the singleton compiler (rust is technically a
>> langauge but in practice it is a single implementation, so far) has very
>> aggressive requirements for the bootstrap compiler.
>
> You might be aware of these, but there are two unrelated projects,
> gcc-rs (Rust front-end for GCC), and rustc_codegen_gcc (GCC back-end
> for rustc). These aren't going to solve the bootstrapping problems,
> but they can improve platform support -- not today, but a 5-year
> timeline seems reasonable.

I am aware of the first.  They may well improve support, but it will
take the rust community to value a stable language specification to the
point where the flagship compiler can build with reasonably recent
versions of gcc-rs.

> This is more subtle than "not caring". Developers care about their
> software enough to be willing to throw away large parts of it, in
> order to be able to use Rust. What they care less about is portability
> to platforms they've never touched. Maybe they work on x86-64 and can
> test on AArch64, but just because somebody does the packaging for GNU
> Hurd, s390x or Amiga, that doesn't mean they are required to support a
> platform they're never going to touch.

That sounds exactly like "not caring".  The point is that if one has
dependencies that have reasonable portability stories, and writes to
POSIX, then you produce things that are mostly portable and others will
send little patches and we all get along fine.  There is no "requirement
to support"; this is about "don't choose to make it effectively
impossible".  In the middle is "there is no reason it shouldn't work,
but if there's a bug please send a patch".

Choosing a dependency that has bad portability is a decision to make
your project not work on platforms that the non-portable dependency has
chosen to not make work.

> See also
> https://blog.yossarian.net/2021/02/28/Weird-architectures-werent-supported-to-begin-with,
> which raises similar points.

Long ago, free software struggled against "everybody should just use
windows".

>> What benefit does a hard requirement bring us, that is more important
>> than the downside of the current and future portability issues?
>
> If I understand correctly, it works around a Python packaging limitation where GDAL can't properly specify or detect its optional dependencies.

I guess there is that vs the try/except, or just let the things that
need to import numpy throw an exception, letting most of the use cases
work.  Surely one doesn't need numpy to read a geojson, or a vector
table out of a geopackage.