-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Driver Management #18
Comments
Sean writes about problems with Python's
finalizer(GDAL, GDAL.destroydrivermanager)
finalizer(GDAL, GDAL.destroy) |
I don't think we can: JuliaLang/julia#8764. The deeper issue is that it isn't clean for driver registration to be a side-effect of importing the module; and it won't be possible for downstream packages to reverse that. |
Ah thanks for the link. Ok I agree on the side-effect not being very clean. Shall we just remove the driver register functions from the |
I think removing the driver registration functions from |
I am trying to catch up a bit with your progress, so sorry for stupid questions. Would this mean that the driver registration and destruction would have to be handled by the user? How would a downstream package handle this? |
Yup, This would mean that driver registration and destruction will have to be handled by downstream packages/users, e.g. import GDAL
GDAL.allregister()
...
GDAL.destroydrivermanager() A downstream package might provide a do-block context e.g. module FriendlierGDAL
import GDAL
function registerdrivers(f::Function)
GDAL.allregister()
try
f()
finally
GDAL.destroydrivermanager()
end
end
end Such that users can do something like import FriendlierGDAL
FriendlierGDAL.registerdrivers() do
...
end |
https://sgillies.net/2014/01/22/rethinking-driver-management-in-fiona-and-rasterio.html
Maybe we should not register all the drivers when importing the module, since we do not call
GDALDestroyDriverManager()
?The text was updated successfully, but these errors were encountered: