[R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing
Edzer Pebesma
edzer@pebe@m@ @end|ng |rom un|-muen@ter@de
Sat Jun 6 17:25:55 CEST 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3110 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20200606/b80060e2/attachment.bin>
More information about the R-sig-Geo
mailing list