[R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

Sat Jun 6 17:32:32 CEST 2020

AFAIK CRAN for macOS relies on the toolstack listed on 
https://mac.r-project.org/libs-4/ and not on homebrew. Though I am not 
100% sure here.
There, static tarballs are used which do not follow a package manager 
versioning scheme (unfortunately, because this would prevent many issues 
for the end user).

-> GDAL 2.4.2 and PROJ 5.2.0

On 6 Jun 2020, at 17:25, Edzer Pebesma wrote:

> Patrick, out of interest: can you point to a CI that mirrors what CRAN
> OSX binary builds do? What I have seen they build on brew, not on
> statically built binaries.
>
> On 6/6/20 4:28 PM, Patrick Schratz wrote:
>> Roger,
>>
>> I am sorry for arguing differently so often recently, but if I think
>> that unfair arguing is going on, I have the feeling to correct this.
>>
>> First, again I think that stating "I do not have access to this 
>> system"
>> is a weak reason in 2020.
>> I've said this previously but again: As a developer/maintainer, there 
>> is
>> the implicit burden to set up a dev environment across different
>> platforms.
>> CI helps here.
>> For more detailed testing, local emulation is possible via virtual
>> machines which also applies to macOS systems (setting up is harder 
>> but
>> not impossible).
>> Before switching back to macOS a few months ago, I had a virtual 
>> machine
>> of macOS running and used it successfully for dev purposes.
>>
>> Second: All package managers seek to provide stability and homebrew 
>> is
>> one of the most sophisticated ones out there.
>> I honestly do not understand the general bashing against package
>> managers here.
>>
>> Third: What role does Apple play in all of this? I am not arguing 
>> that
>> they made some decisions that did not necessarily enhance the dev
>> experience on macOS.
>> However, I do not see any of these having an effect on the spatial
>> library stack, especially GDAL and PROJ.
>>
>> The current situation is that the **main** package manager on macOS,
>> namely homebrew, has a temporary version situation of GDAL and PROJ 
>> that
>> is (for no clear reason yet) blocked by the client package rgdal.
>>
>> Users on macOS can however use the formulas of the osgeo4mac
>> (https://github.com/OSGeo/homebrew-osgeo4mac) tap which comes with 
>> PROJ7
>> and GDAL3 to solve these issues.
>>
>> ```r
>> brew tap osgeo/osgeo4mac
>> brew unlink gdal
>> brew unlink proj
>>
>> brew install osgeo-gdal
>> brew install osgeo-proj
>> brew link osgeo-gdal
>> brew link osgeo-proj
>> ```
>>
>> I am well aware that many users of spatial software are not 
>> developers
>> in their every day life and should stick to binaries.
>> However, there is a group that does source installs and there are CI
>> checks that rely on proper source installations with the current 
>> stack
>> of the main package managers on a platform.
>> And exactly this group is blocked right now by blocking the rgdal
>> installation at all, with a somewhat weak reasoning for this action.
>>
>> In addition, arguing/ranting about specific platforms with points
>> unrelated to the current issues is a thing that I absolutely dislike,
>> getting me started arguing against it.
>> I also do not like certain platforms and have personal favorites.
>> However, I always check on all and make sure that everyone gets a
>> pleasant experience on their platform, even if that's painful for me 
>> and
>> costs a lot of time.
>>
>> I am well aware that I might not be invited to the next imaginary 
>> party
>> with my arguing here but maybe the discussion can make use of more 
>> real
>> facts again, lower subjective views, and focus on providing support 
>> for
>> everyone, on all platforms, without introducing something like a
>> "platform racism" with semi-fake news.
>>
>> Best, Patrick
>>
>> On 6 Jun 2020, at 15:45, Roger Bivand wrote:
>>
>>> On Sat, 6 Jun 2020, Ista Zahn wrote:
>>>
>>>> On Fri, Jun 5, 2020 at 7:47 PM Manuel Spínola 
>>>> <mspinola10 using gmail.com>
>>>> wrote:
>>>>>
>>>>> Dear list members,
>>>>>
>>>>> Sorry for the confusion, but with all these suggestions, what is 
>>>>> the
>>>>> way to
>>>>> have the updated versions of the external
>>>>> software GEOS, PROJ, and GDAL for macOS users.
>>>>
>>>> I think the current recommendation is "if you have to ask don't do
>>>> it". Just wait for these to be updated in the OSX binary packages 
>>>> on
>>>> CRAN.
>>>
>>> Thanks, a much better way of saying this!
>>>
>>> We really would like to be able to help macOS users who see "Install
>>> from source?" and are tempted to choose "yes", but not only do we 
>>> not
>>> have the resources or access to running systems, but also, at the
>>> moment, things seem very unpredictable. We do not think that
>>> environments are helpful, and many package managers do not seem to
>>> have sufficient focussed attention, which is understandable given
>>> Apple's gift for moving the goalposts.
>>>
>>> If users can install external software from source (macOS, Linux),
>>> they/we have a good deal of freedom. But this takes time, insight, 
>>> and
>>> for many is problematic because their production system is blocked
>>> until the new versions are ready (PROJ and GDAL are C++11 or more, 
>>> and
>>> take an order of magnitude longer to compile than just a few years
>>> ago).
>>>
>>> So for Windows and macOS, waiting for the CRAN binaries is a
>>> reasonable choice.
>>>
>>> Beyond this, we need to find ways of providing share/proj and
>>> share/gdal metadata files for all of the packages now using the PROJ
>>> and GDAL libraries, and of navigating the content download network 
>>> for
>>> geodetic transformation grids available from PROJ 7. But that is
>>> another story ...
>>>
>>> Roger
>>>
>>>>
>>>> Best,
>>>> Ista
>>>>
>>>>>
>>>>> Manuel
>>>>>
>>>>> El vie., 5 jun. 2020 a las 14:31, Patrick Schratz (<
>>>>> patrick.schratz using gmail.com>) escribió:
>>>>>
>>>>>> I am not sure if the part with
>>>>>>
>>>>>> use --with-proj_api="proj_api.h" for deprecated API
>>>>>>
>>>>>> Is of much help since c/p won’t work but the text let’s 
>>>>>> people
>>>>>> assume that c/p could/should work.
>>>>>> In fact, a full path to “proj_api.h” is required?
>>>>>>
>>>>>> I still do not like this blocker and I still do not know if this
>>>>>> combination causes serious issues in production or just limits 
>>>>>> new
>>>>>> features.
>>>>>>
>>>>>> For the time being, using and linking osgeo-gdal (3.0.1) and
>>>>>> osgeo-proj
>>>>>> (7.0.1) works and can be used as a workaround until homebrew-core
>>>>>> formulas catch up.
>>>>>>
>>>>>>> checks OK on PROJ 7.0.1 and GDAL 2.2.4
>>>>>>
>>>>>> Again, since it was maybe caused by my typo a few mails ago: The
>>>>>> homebred-core gdal version is at 2.4.4 and not 2.2.4.
>>>>>>
>>>>>> On 5 Jun 2020, at 13:29, Roger Bivand wrote:
>>>>>>
>>>>>>> The release candidate of rgdal_1.5-9 is ready for testing on
>>>>>>> R-forge:
>>>>>>>
>>>>>>> https://r-forge.r-project.org/R/?group_id=884
>>>>>>>
>>>>>>> Those insisting on installing on PROJ >= 6 and GDAL < 3 must use
>>>>>>> configure argument --with-proj_api="proj_api.h"; with this used,
>>>>>>> this
>>>>>>> version builds with --no-build-vignettes and installs and checks
>>>>>>> OK on
>>>>>>> PROJ 7.0.1 and GDAL 2.2.4 with --with-proj_api="proj_api.h".
>>>>>>>
>>>>>>> Otherwise checked OK with PROJ 4.8.0, 4.9.2, 4.9.3 and 5.2.0 
>>>>>>> with
>>>>>>> GDAL
>>>>>>> 1.11.4; with PROJ 5.2.0 and GDAL 2.2.4, 2.3.2 and 2.4.2; with 
>>>>>>> PROJ
>>>>>>> 6.3.2 and GDAL 3.0.4; with PROJ 7.0.1 and GDAL 3.0.4 and 3.1.0.
>>>>>>>
>>>>>>> All who have indicated issues with source installs are asked to
>>>>>>> try
>>>>>>> the release candidate and to report back here by midnight CEST
>>>>>>> Monday
>>>>>>> 8 June. If no indications are forthcoming, I'll assume that
>>>>>>> problems
>>>>>>> with 1.5-8 are resolved.
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>> --
>>>>>>> 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 using nhh.no
>>>>>>> https://orcid.org/0000-0003-2392-6140
>>>>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> R-sig-Geo mailing list
>>>>>>> R-sig-Geo using r-project.org
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>>>
>>>>>> _______________________________________________
>>>>>> R-sig-Geo mailing list
>>>>>> R-sig-Geo using r-project.org
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Manuel Spínola, Ph.D.*
>>>>> Instituto Internacional en Conservación y Manejo de Vida 
>>>>> Silvestre
>>>>> Universidad Nacional
>>>>> Apartado 1350-3000
>>>>> Heredia
>>>>> COSTA RICA
>>>>> mspinola using una.cr <mspinola using una.ac.cr>
>>>>> mspinola10 using gmail.com
>>>>> Teléfono: (506) 8706 - 4662
>>>>> Personal website: Lobito de río
>>>>> <https://sites.google.com/site/lobitoderio/>
>>>>> Institutional website: ICOMVIS <http://www.icomvis.una.ac.cr/>
>>>>>
>>>>>         [[alternative HTML version deleted]]
>>>>>
>>>>> _______________________________________________
>>>>> R-sig-Geo mailing list
>>>>> R-sig-Geo using r-project.org
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>
>>>> _______________________________________________
>>>> R-sig-Geo mailing list
>>>> R-sig-Geo using r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>
>>>
>>> -- 
>>> 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 using nhh.no
>>> https://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en_______________________________________________
>>> R-sig-Geo mailing list
>>> R-sig-Geo using r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>> 	[[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
> -- 
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48149 Muenster, Germany
> Phone: +49 251 8333081
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo using r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo