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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Howard Butler-3
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.


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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

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

ginetto
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
* Hire a team: http://www.qcooperative.net
**************************************************************************************************


On Tue, 14 Jan 2020 at 16:12, Howard Butler <[hidden email]> 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.


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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal

_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

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

Doug Newcomb
In reply to this post by Howard Butler-3
That sounds like it will give more flexibility going forward.
Doug

On Tue, Jan 14, 2020 at 10:12 AM Howard Butler <[hidden email]> 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.


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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal

_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

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

adam steer-2
Hi Howard

I’m reading that in future, filters.python and readers.numpy will still exist, they will just require installing PDAL-python and configuring PDAL_DRIVER_PATH correctly.

That sounds all good to me.

Regards,

Adam

_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

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

Howard Butler-3


> On Jan 15, 2020, at 5:12 PM, adam steer <[hidden email]> wrote:
>
> Hi Howard
>
> I’m reading that in future, filters.python and readers.numpy will still exist, they will just require installing PDAL-python and configuring PDAL_DRIVER_PATH correctly.

Correct. If you have PDAL_DRIVER_PATH already set, or it can be found by the python setup.py script by issuing 'pdal-config --plugin-dir', they will be installed there for you and should just work without intervention.

Howard
_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal