Explicitly require libproj >= 6

Question

Explicitly require libproj >= 6

Closed this issue 7 months ago · 12 comments

libproj >= 6 should be a safe dependency now? Can we explicitly require libproj >= 6 and fail to install PROJ if this dependency isn't met?

Answer 1 · 2023-12-04T02:18:34.000Z

yes, happy to make this is a hard dep now

Answer 2 · 2023-12-04T07:29:41.000Z

I think the minimum needed here is to remove the conditionals #ifdef USE_PROJ6_API.

We should also:

remove the USE_PROJ6_API macro
deprecate ok_proj6()

Answer 3 · 2023-12-04T07:33:30.000Z

Ok no problem, I internalized the ok_proj6 logic to reproj itself and removed the import, so I'm not worried about that now. I'm pretty confident that osmdata and mapscanner will continue to work with reproj falling back to proj4 if needed (I'll release reproj in a day or so).

Go ahead and do this (or just give me a list to work through). Thanks!!

Answer 4 · 2023-12-04T09:12:17.000Z

Closed in #42

Answer 5 · 2023-12-10T11:42:40.000Z

@mdsumner @anthonynorth Is it possible to add an explicit configure option to choose a specific Proj version installed locally? Instead of letting pkgconfig randomly pick something, creating a chaos.

Answer 6 · 2023-12-10T11:53:43.000Z

it's possible and libproj provides this - install it from github

this was tried in collaboration with CRAN but Brian Ripley (seemingly without consultation) vetoed it and threatened the maintainer with a lifetime ban, seemingly because of email problems on the CRAN side

none of this was carried out in public, btw but I'm happy to share the communications I was privy to if you like.

libproj works fine, though you just have to let go of cran (if this project can facilitate a new scheme remains to be seen!)

😃

Answer 7 · 2023-12-10T12:16:29.000Z

@mdsumner I do not use CRAN at all, aside of borrowing tarball sources from there, when no released versions are offered by upstream repos (in which case I still install via Macports).

However it seems desirable to be able to use already installed proj since we do need it anyway – for other, non-R software. Requiring to build another version to use internally for R is feasible, but appears wasteful.

I can make a port for libproj, that does not hurt, but having flexibility with configure options will be great. (All other proj-related R packages provide configure args to pick a particular version, here it seems that I will need to do some ugly patching to make it work.)

Answer 8 · 2023-12-11T02:00:10.000Z

oh I'm sorry, I totally misread your post ...

Yes, I need to fix configure so it can be used to set PROJ. Apologies

Answer 9 · 2023-12-11T05:57:15.000Z

Perhaps we could look at adopting something like Jeroen's anticonf?

https://github.com/jeroen/curl/blob/7804f59f9bb91537fe9bebbe0655a07acb31eb5c/configure#L3-L6

Answer 10 · 2023-12-11T06:33:10.000Z

that's my preference, it's so much simpler. I don't think all the tests done for rgdal/sf are really needed anymore.

but, it will have to deal with the location of the proj data too, and I'm trying to navigate understanding what the proj4 and sf configures do different - it seems to me that env vars PKG_CPPFLAGS and PKG_LIBS could be used but the proj4 configure doesn't seem to apply these exclusively from pkg-config, and sf configure uses --with-proj-libs configure arguments (the configure.ac here was modelled from proj4)

I'm trying to understand enough of it to rewrite ... - a danger with anticonf will be angering CRAN if we miss something that's covered in the sf case, because they contributed to that and consider it authorative.

It's possible to copy and paste the sf configure.ac, and rip out the GDAL and GEOS parts but we'd also need to ensure it doesn't try to work with version 5 or 4. And then there's different env vars vs configure vars settings with different names to decide about ... I can't quite get hold of enough of it to know what's best 😅

Answer 11 · 2023-12-11T08:17:03.000Z

@mdsumner There are several R packages which use configure args to pick Proj version, perhaps like 4–5. We have 8 which depend on Proj now (see lib dependents list; they use Proj5, which I need to change now): https://ports.macports.org/port/proj/details
I can check which of those use configure once I am on a Desktop with BBEdit :)

On a side note, if you gonna borrow configure from another package, it would be great not to force brewisms on MacOS. Unfortunately some R packages do that, and that is wrong. It should be controllable from a user side which package manager to use, if any (and we got at least 3 major ones on Mac).

Answer 12 · 2023-12-11T23:43:49.000Z

I've created an issue for this #43