<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">All,<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">* Python modules can evolve at their own (maybe faster) pace</div><div class="">* The current approach pins the main PDAL library to a specific Python version which complicates packaging</div><div class="">* Current CMake config for install of Python plugins is not aware of virtualenvironment specifics unless you are using very current CMake versions.</div><div class=""><br class=""></div><div class="">PDAL: <a href="https://github.com/PDAL/PDAL" class="">https://github.com/PDAL/PDAL</a> </div><div class="">PDAL-python: <a href="https://github.com/PDAL/python/" class="">https://github.com/PDAL/python/</a></div><div class=""><br class=""></div><div class="">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 <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Howard</span></div></div></div></div></body></html>