[pdal] Proposal: Move all Python support to the Python extension in PDAL 2.1

[Luigi Pirelli]

yes please :)

Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition
<https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition>
* Hire a team: http://www.qcooperative.net
**************************************************************************************************


On Tue, 14 Jan 2020 at 16:12, Howard Butler <howard at hobu.co> wrote:

> All,
>
> This proposal is to solicit feedback on moving readers.numpy and
> filters.python out of the main PDAL library and into the PDAL Python
> extension going forward.  The case for doing so is a number of factors:
>
> * Python modules can evolve at their own (maybe faster) pace
> * The current approach pins the main PDAL library to a specific Python
> version which complicates packaging
> * Current CMake config for install of Python plugins is not aware of
> virtualenvironment specifics unless you are using very current CMake
> versions.
>
> PDAL: https://github.com/PDAL/PDAL
> PDAL-python: https://github.com/PDAL/python/
>
> The prototype implementation removes all embedded Python plugins
> (readers.numpy and filters.python)  from the main PDAL library. It moves
> them to PDAL-python, which are then installed in PDAL_DRIVER_PATH when
> setup.py install is executed. If no PDAL_DRIVER_PATH is set in the
> environment or found via pdal-config, the plugins will be installed in the
> Python library path and PDAL users will have to append or set that path to
> the PDAL_DRIVER_PATH location.
>
> I am interested to hear feedback on whether or not this proposal will
> cause trouble with existing deployments. While it might reduce some user
> convenience, I think it is prudent to make PDAL behave like any other
> library in regard to language extensions, which will also have the benefit
> of allowing the language extensions to evolve at their own pace.
>
> Please reply to describe how this new arrangement could cause you
> challenges. If possible, we can try to accommodate if we know what they
> might be.
>
> Howard
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200114/dad0eda5/attachment.html>