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 <[email protected]> >>> 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 (< >>>> [email protected]>) 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: [email protected] >>>>>> https://orcid.org/0000-0003-2392-6140 >>>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en >>>>>> >>>>>> _______________________________________________ >>>>>> R-sig-Geo mailing list >>>>>> [email protected] >>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>> >>>>> _______________________________________________ >>>>> R-sig-Geo mailing list >>>>> [email protected] >>>>> 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 >>>> [email protected] <[email protected]> >>>> [email protected] >>>> 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 >>>> [email protected] >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> [email protected] >>> 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: [email protected] >> https://orcid.org/0000-0003-2392-6140 >> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en_______________________________________________ >> R-sig-Geo mailing list >> [email protected] >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Edzer Pebesma Institute for Geoinformatics Heisenbergstrasse 2, 48149 Muenster, Germany Phone: +49 251 8333081
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ R-sig-Geo mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-geo
