<div dir="ltr"><div>Hi Even,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2020 at 7:53 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On vendredi 31 janvier 2020 15:14:39 CET Mateusz Loskot wrote:<br>
> On Fri, 31 Jan 2020 at 10:58, Christoph Paulik <<a href="mailto:cpaulik@vandersat.com" target="_blank">cpaulik@vandersat.com</a>> <br>
wrote:<br>
> > My initial motivation was that I would like `pip install gdal` to just<br>
> > work.<br>
> I do share your view.<br>
> The pip install is always the canonical Pythonic way for me and<br>
> I'd be very happy myself to be able to install GDAL that way.<br>
> <br>
> > I guess that it is unrealistic to fix any of that, so let's get back on<br>
> > topic.<br>
> My point is that, IMO, such initiative is best to be run as a project<br>
> independent from GDAL development, outside GDAL repository,<br>
> for practical reasons.<br>
<br>
Except that if we wanted "pip install gdal" to include wheels, that should be <br>
done as part of the gdal Pyython package that is managed in swig/python of <br>
GDAL repository. Something outside should use another package name<br></blockquote><div><br></div><div>Speaking of package name, "gdal" and "ogr" are modules of an "osgeo" package. Maybe it should be "pip install osgeo"? Doesn't need to be, of course, but it's nice when distribution and package names match.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<brainstorming><br>
Thinking about Sean's very valid point about wheels and symbol clashes when <br>
loading different version of the same library (or perhaps even the same <br>
version twice), I'm wondering if using symbol versioning, at least on Linux, <br>
wouldn't solve this. Imagine that you'd recompile GDAL and all its <br>
dependencies such that all exported symbols (functions & global variables), <br>
with some "gdal_wheel" marker, then those libraries would be effectively <br>
private to the Python package. I know that at some past point (GDAL 1.8 I <br>
think), Debian packaged GDAL with versionned symbols (from a distribution <br>
point of view, versionned symbols aren't necessarily that great from what I <br>
read, but for the use case we discuss here, that could perhaps be an option). <br>
<br>
Hopefully, there would be some existing tools to automate this. At linking <br>
time. Or perhaps as a post processing stage, messing directly with the ELF <br>
format.<br></blockquote><div><br></div><div>There are existing tools. Multibuild uses <a href="https://github.com/pypa/auditwheel">https://github.com/pypa/auditwheel</a>. It says in the project README that the result is "like static linking", but as I've found between rasterio and h5py wheels (which both have been through auditwheel), it's not proof against conflicts.</div><div><br></div><div><a href="https://github.com/matthew-brett/delocate">https://github.com/matthew-brett/delocate</a> is the OS X analog of auditwheel.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I could imagine thought that symbol renaming/versionning wouldn't fly very <br>
well with dlopen()/dlsym() use that libraries could make. But I don't think <br>
this is extensive used in the GDAL use case. On top of my head, a few cases <br>
might be:<br>
* typically the old way GDAL loaded PROJ4. But no longer an issue with GDAL 3, <br>
or can be avoided with GDAL 2.x as well when building with --with-<br>
[static-]proj[4])<br>
* the OGDI library loading its plugin. But OGDI is sufficiently a odd beast <br>
that we don't need/want this in a general purpose wheel.<br>
</brainstorming><br>
<br>
Even<br></blockquote><div><br></div><div>Even though I'm not a user of GDAL's python bindings, it's clear that my project is going to benefit from having your Linux expertise focussed on the problem of getting GDAL and its dependencies to Python users, and I'm grateful for that.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Sean Gillies</div></div></div>