Hi,
cf https://github.com/OSGeo/gdal/pull/8926 for a proposed resolution
that is hopefully a good-enough compromise. In short, numpy as a *build*
requirement (if using pip. if you use setuptools directly, you may set
an env var if you really really don't want to have numpy in your way),
but
Laurențiu Nicola via gdal-dev 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
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
Laurențiu Nicola via gdal-dev writes:
> 1. do the platforms you care about package Firefox, librsvg, or any
> other popular software that's using Rust?
pkgsrc supports multiple operating system, multiple versions of those
systems, and multiple cpu architectures. There are probably over a
> On Dec 4, 2023, at 4:51 PM, Daniel Evans via gdal-dev
> wrote:
>
> Agree with Kurt - it's always struck me as a little surprising that it was
> optional.
GDALs bindings predate Numpy. We spanned over the Numeric/Numarray transition
IIRC too.
Hi Greg,
I'd like to better understand your concerns, so I have a couple of questions
and remarks:
1. do the platforms you care about package Firefox, librsvg, or any other
popular software that's using Rust?
2. do you have any reasons to believe that numpy will require Rust in the
future? I
Thomas Knudsen writes:
> Den tirs. 5. dec. 2023 kl. 02.15 skrev Greg Troxel via gdal-dev <
> gdal-dev@lists.osgeo.org>:
>> Building the
>> rust compiler requires the *immediately preceding* compiler, which seems
>> unprecented, and I don't understand how people can think that's ok
>
> I don't
Den tirs. 5. dec. 2023 kl. 02.15 skrev Greg Troxel via gdal-dev <
gdal-dev@lists.osgeo.org>:
> Building the
> rust compiler requires the *immediately preceding* compiler, which seems
> unprecented, and I don't understand how people can think that's ok
I don't think this is true - it's merely the
Even Rouault via gdal-dev writes:
> The current situation where numpy is an optional dependency of the
> GDAL Python bindings is quite cumbersome to deal with our setup.py's
> setuptools . All details (a bit tricky) in
> https://github.com/OSGeo/gdal/issues/8069 . It seems it would be
> simpler
For what it's worth, Rasterio has required Numpy for a few versions, and
there's never been a single complaint about it. The footprint and extra
complexity of numpy is just a drop in the bucket.
I suppose that someone using only the OGR parts of the Python bindings
might be inconvenienced, but
Agree with Kurt - it's always struck me as a little surprising that it was
optional. There's also not very much of a Python stack you can build that
involves GDAL but doesn't pull in Numpy through another dependency, as Even
said.
I would've thought that in any constrained environment where GDAL
I lean towards just requiring numpy. It's super common and once a system
brings in gdal python, it can't be a super constrained env where keeping
things really small is critical. Just requiring numpy simplifies a number
of aspects.
I think the setup.py topic as a whole is somewhat separate.l. So
Hi,
The current situation where numpy is an optional dependency of the GDAL
Python bindings is quite cumbersome to deal with our setup.py's
setuptools . All details (a bit tricky) in
https://github.com/OSGeo/gdal/issues/8069 . It seems it would be simpler
if the bindings just required numpy,
13 matches
Mail list logo
