We currently call proj_context_set_search_paths in __init__ to make it find the share/proj data that always comes with PROJ_jll. However if proj_context_set_search_paths is used then it doesn't look further down the documented location order: "If set, the next tests will not be run." I'm assuming that means it will stop there, whether the file is found or not.
We probably don't need to call proj_context_set_search_paths in __init__ since the artifact uses the standard prefix layout so it should find it relative to the shared library at ../share/proj/. A benefit of not using it is that we will be open to users setting PROJ_DATA, as well as looking in the PROJ user writable directory. Otherwise it needs to be explicitly added by users getting grids, as in https://github.com/JuliaGeo/Proj.jl/issues/75#issuecomment-1380549902.
It can also be a conscious decision to keep the call to proj_context_set_search_paths in __init__ to isolate Proj.jl from system wide configuration settings, as it is now. I'm not sure how easy or common it is to break things based on these settings however. Though I'm not really looking forward to debugging user issues related to unintentional system wide configurations.
If we want to keep things isolated from system wide settings by default, we should have a good julia specific location to write grids to with projsync. One option worth looking into would be to use https://github.com/JuliaPackaging/Scratch.jl for this, and then during __init__ add that to the search path: Proj.proj_context_set_search_paths(2, [Proj.PROJ_DATA[], scratch_dir]). This does allow it to find grids you downloaded in previous julia sessions to the scratch dir, and any julia-specific bad resource state can be wiped using clear_scratchspaces!(Proj).
This refers to the docs at https://proj.org/resource_files.html#where-are-proj-resource-files-looked-for.
We currently call
proj_context_set_search_pathsin__init__to make it find theshare/projdata that always comes with PROJ_jll. However ifproj_context_set_search_pathsis used then it doesn't look further down the documented location order: "If set, the next tests will not be run." I'm assuming that means it will stop there, whether the file is found or not.We probably don't need to call
proj_context_set_search_pathsin__init__since the artifact uses the standard prefix layout so it should find it relative to the shared library at../share/proj/. A benefit of not using it is that we will be open to users settingPROJ_DATA, as well as looking in the PROJ user writable directory. Otherwise it needs to be explicitly added by users getting grids, as in https://github.com/JuliaGeo/Proj.jl/issues/75#issuecomment-1380549902.It can also be a conscious decision to keep the call to
proj_context_set_search_pathsin__init__to isolate Proj.jl from system wide configuration settings, as it is now. I'm not sure how easy or common it is to break things based on these settings however. Though I'm not really looking forward to debugging user issues related to unintentional system wide configurations.If we want to keep things isolated from system wide settings by default, we should have a good julia specific location to write grids to with
projsync. One option worth looking into would be to use https://github.com/JuliaPackaging/Scratch.jl for this, and then during__init__add that to the search path:Proj.proj_context_set_search_paths(2, [Proj.PROJ_DATA[], scratch_dir]). This does allow it to find grids you downloaded in previous julia sessions to the scratch dir, and any julia-specific bad resource state can be wiped usingclear_scratchspaces!(Proj).