[PROJ] Disable .local in 7.0.0RC default search paths

[Roger Bivand]

Even,

On Sun, 23 Feb 2020, Even Rouault wrote:

> Roger,
>
>> Trying out the RC with R package rgdal (Fedora 31), I see
>> proj_info().searchpath returning:
>>
>> "/home/rsb/.local/share/proj:/usr/local/share/proj:/usr/local/share/proj"
>>
>> Where in the documentation or code is the recipe for disabling the
>> creation of and writing of cache.db to .local/share/proj? No R package is
>> permitted to write anything without positive user confirmation to anywhere
>> other than R's per-session temporary directory.
>
> Nothing is written in this directory, nor it is created, unless you enable
> explicitly network functionality or use the new projsync utility.

Where are these functions, and can they be securely turned off (confirmed 
on load that CDN will not be used)? Later users or labs may turn them on, 
but positive confirmation that they are off matters.

>
> If you don't want this directory to be looked for at all, you may call
> proj_context_set_search_paths() to override the default search paths.
>

On load, proj_info().searchpath regularly returns the string I reported 
with 7.0.0RC, rather than /usr/local/share/proj (expected). I think that 
the reporting needs to be more fine-grained (proj.db found in directory; 
the directory where PROJ will cache CDN grids if enabled; other 
directories). I've seen transient cases of rgdal loading, creating the 
directory and putting cache.db in it, and other cases where no directory 
is created, in otherwise identical settings.

>> pj_context_get_user_writable_directory(), which only takes the context and
>> a boolean set defauly TRUE I think
>
> No, the boolean has no default value. It is always called with 
> create=false in filemanager.cpp. Only with create=true in 
> networkfilemanager.cpp when network functionality is enabled
>
> Obviously this should reassure you. PROJ 7 will hopefully not eat your
> children :-)
>

Not my children, just CRAN admins needing to know that no package ever 
creates files or directories outside controlled space (best the tempdir of 
the R session) by simply being loaded and tests and examples run. Then 
almost 1000 packages using sf or rgdal directly or indirectly for 
production work, teaching and research, over which we have little or no 
control, and who are not ready for 6 or 7.

Earlier, you asked for views from institutional users about RFC4. I asked, 
but none replied, because I'm sure they do not grasp what the impact on 
their workflows will be. We'll have to tag each executed coordinate 
operation with metadata not just from the pipline used (done in rgdal), 
but if grids come into play, with a hash tag or similar of the specific 
grid used - to be able to reproduce the output of the coordinate 
operation. Will that be visible in the pipeline string returned?

R packages do need this for reproducibility of results, so that we know 
when differences in output from the same input and code come from changes 
in the package interfacing the PROJ API, PROJ itself, or a grid section 
grabbed from the CDN at two different points in time.

Roger

> Even
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en