Closed theroggy closed 2 weeks ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml
) and found it was in an excellent condition.
@conda-forge-admin please rerender
@ocefpaf as described in the PR description above, we wonder if conda offers an option to depend on libgdal-core
, but if (another dependency in) the conda environment needs an older version of GDAL, it would fallback to libgdal
. Could you shed some light, or is depending on the gdal
package the way to go?
@ocefpaf as described in the PR description above, we wonder if conda offers an option to depend on
libgdal-core
, but if (another dependency in) the conda environment needs an older version of GDAL, it would fallback tolibgdal
. Could you shed some light, or is depending on thegdal
package the way to go?
If something requests older GDAL, an older build of pyogrio would also be selected. If you want to keep that as an option for future versions, then a variant would need to be built. IMO it is not worth the effort. Even more so given that the current pyogrio will be available for both for a while if we merge this one.
With that said. you are depending on gdal
only here, that means conda will solve for whatever libgdal(-core or not) the gdal
version requested is available.
Does that make sense?
If something requests older GDAL, an older build of pyogrio would also be selected. If you want to keep that as an option for future versions, then a variant would need to be built. IMO it is not worth the effort. Even more so given that the current pyogrio will be available for both for a while if we merge this one.
With that said. you are depending on
gdal
only here, that means conda will solve for whatever libgdal(-core or not) thegdal
version requested is available.Does that make sense?
Yes. This is indeed the reason I created this PR to depend on gdal
. I expected this to be the only/best (practical) solution to be able to have recent versions of pyogrio
use libgdal-core
for new GDAL versions and libgdal
for older GDAL versions.
Based on your answer, I think you agree?
But (and that's something I forgot when we chatted about this in our meeting), pyogrio binaries are built against a specific version of GDAL anyway. So it's not actually possible to install the latest pyogrio (assume the resulting binary of this rerendering) with an older version of GDAL.
In that case the concern is a bit moot and it is actually fine to just directly depend on libgdal-core
?
Yes, indeed... in the corresponding rasterio issue I created (https://github.com/conda-forge/rasterio-feedstock/issues/303) this also was just mentioned...
I already encountered the case that with global pinning a rebuild was needed to use the latest version, but apparently the pinning is really on a specific version... Kind of a weird situation, as in pyogrio we try to support keep support older gdal versions as well and the GDAL C API is binary compatible as far as I know...
Another point raised in the rasterio topic: maybe better to wait for the next version (0.10 for pyogrio) as it can be seen as it can break an installation, even if it is easy to solve it?
Hello there, I am looking forward to this change being merged to slim down our environments. I see very few, if any, open issues are linked to the 0.10 milestone: is there any target release date for 0.10 and the change in feedstock?
@olivier-lacroix indeed, we hope to release shortly. I opened an issue to track the release at https://github.com/geopandas/pyogrio/issues/470
Thanks @jorisvandenbossche ! Looking forward to it!
GDAL recently reorganised its conda packages as discussed in https://github.com/conda-forge/gdal-feedstock/issues/722. In short: the
libgdal
package was split up in a core package,libgdal-core
, and a list of seperate packages for many GDAL plugins, to be able to avoid the (large) footprint of the entirelibgdal
. Forpyogrio
this is also very relevant, as it depends onlibgdal
and mostpyogrio
users only needlibgdal-core
.However, as
libgdal-core
only exists for GDAL 3.9.1, just depending onlibgdal-core
would mean - as far as I know - that users of future versions ofpyogrio
could only install that new version in combination with GDAL 3.9.1, not with older versions of GDAL, as for those only the fulllibgdal
package exists.Because of this, this PR at the moment "proposes" to changed the dependency to the
gdal
package. This is the GDAL package with python bindings (which aren't needed forpyogrio
), but the advantage is that for old versions of GDAL this depends onlibgdal
, but starting from GDAL 3.9.1 it depends onlibgdal-core
, so it can offer a workaround for the issue above.If conda would offer an option to depend on
libgdal-core
, but if not available (for the needed version of GDAL), fallback tolibgdal
, that would be even better.Closes #48.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)