<div dir="ltr">That sounds like it will give more flexibility going forward.<div>Doug</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020 at 10:12 AM Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</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"><div style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;">All,<div><br></div><div>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><br></div><div>* Python modules can evolve at their own (maybe faster) pace</div><div>* The current approach pins the main PDAL library to a specific Python version which complicates packaging</div><div>* Current CMake config for install of Python plugins is not aware of virtualenvironment specifics unless you are using very current CMake versions.</div><div><br></div><div>PDAL: <a href="https://github.com/PDAL/PDAL" target="_blank">https://github.com/PDAL/PDAL</a> </div><div>PDAL-python: <a href="https://github.com/PDAL/python/" target="_blank">https://github.com/PDAL/python/</a></div><div><br></div><div>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="color:rgb(0,0,0)">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><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">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><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">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><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Howard</span></div></div></div></div></div>_______________________________________________<br>
pdal mailing list<br>
<a href="mailto:pdal@lists.osgeo.org" target="_blank">pdal@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pdal" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pdal</a></blockquote></div>