[gdal-dev] Requiring numpy for the Python bindings

[Laurențiu Nicola]

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 have no particular reason to believe it will happen.  I have seen many
> things switch to rust and cause portability problems, and there appears
> to be little concern for that during the switching process.  I don't
> know if that's not understanding, not caring, thinking that switching is
> so important that it is worth the harm, or something else I haven't
> thought of.  I therefore find it hard to reason about these choices made
> by others.

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.

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

>> 6. if you're more worried about the availability of an up-to-date Rust
>> toolchain, note that a lot of "foundational" Rust libraries have
>> relatively conservative toolchain requirements. For example, the numpy
>> crate (unrelated to the Python package) supports on Rust 1.48, which
>> is from November 2020 [3].
>
> Generally from a security viewpoint, it's only ok to run maintained
> versions.  But yes, it may be that we version rust and support old, if
> rust portability deteriorates.

I mean, it builds on 1.48, but still works on future versions. If NetBSD has 1.70, it will certainly build on that version. 1.48 is just the minimum required toolchain.

> 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.

Laurentiu