Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please remove dependencies on **rgdal**, **rgeos**, and/or **maptools** #27

Closed
rsbivand opened this issue Dec 14, 2022 · 14 comments
Closed

Comments

@rsbivand
Copy link

This package depends on (depends, imports or suggests) raster and one or more of the retiring packages rgdal, rgeos or maptools (https://r-spatial.org/r/2022/04/12/evolution.html). Since raster 3.6.3, all use of external FOSS library functionality has been transferred to terra, making the retiring packages very likely redundant. It would help greatly if you could remove dependencies on the retiring packages as soon as possible.

@basille
Copy link
Collaborator

basille commented Dec 19, 2022

Thanks @rsbivand for your message. Indeed, rpostgis is due a major update to migrate to sf/stars/terra. Unfortunately, I don't have the time or energy to work on this in the foreseeable future. However, given the recent developments of said packages, the question of the actual relevance of rpostgis is even open: As far as I know, sf can handle the bulk of vector-related functions of the package — it's still not clear if stars/terra can do the raster counterpart. So is rpostgis still useful? It might be time for its retirement altogether.

@rsbivand
Copy link
Author

The package has a single CRAN dependency lucas. While sf has a separate DB vector reading architecture, I'm unsure about terra and stars. You could ask lucas whether they need rpostgis sufficiently to want to help upgrade. You could also raise an issue on https://github.com/r-spatial/discuss/issues maybe linking to this issue, asking whether anyone could run some comparative checks of vector and raster functionality, so aiming to create a table of alternatives to rpostgis workflows.

@basille
Copy link
Collaborator

basille commented Dec 22, 2022

Thanks @rsbivand, this is both excellent information and suggestion. It may well have to wait until January so I can free up some time to do it properly though. Depending on the actual need for rpostgis in the current R landscape (my evaluation is not that much), it might also be worth asking ROpenSci to get a broader engagement.

I'll leave this issue open until the actual dependency problem is solved, and I'll open a different one to report updates about the future of rpostgis.

@rsbivand
Copy link
Author

Are we any closer to a resolution? I haven't seen much movement on r-spatial/discuss#58, so maybe your evaluation is realistic. If we are moving to archival, please ask CRAN to archive rpostgis before October.

@basille
Copy link
Collaborator

basille commented Apr 20, 2023

Unfortunately, nothing really new. Before asking for archival, I'd like to update the package so that a warning is issued on startup. I'll try to do this soon so that the package can be more safely archived in a few months. I'll leave this issue open until then — not hoping for a much different outcome, but simply as a reminder that the problem is still pending.

Thanks @rsbivand for your help and support!

@rsbivand
Copy link
Author

Maybe move to archiving? I emailed the lucas maintainer, perhaps there will be a response?

@basille
Copy link
Collaborator

basille commented Jul 16, 2023

Hey @rsbivand, thanks for the update! We've added a startup warning for rpostgis, that reads:

This is 'rpostgis' version 1.4.4 (2023-05-06).

Due to retirement of the package 'rgeos', 'rpostgis' will retire in September 2023.
  * For vector operations, please check package 'sf', which provides a mechanism to connect to PostGIS databases.
  * For raster operations, no alternative solution is identified yet.
  * For general database operations, use 'RPostgreSQL' directly.

If you are interested in the development and maintenance of 'rpostgis', please check:
https://github.com/mablab/rpostgis/issues/28

So we intend to retire the package in a couple of months. Let's see what happens in the meanwhile, but I already contacted lucas's maintainer about 6 months ago, to no avail. (note that we weren't aware that reading rasters from PostGIS works with both terra and stars so that the warning is partially incorrect)

If that's OK, I'll leave this issue open until rpostgis is retired, or until a new maintainer takes it up.

@rsbivand
Copy link
Author

@basille sounds like a viable plan!

@rsbivand
Copy link
Author

@basille Less than three weeks remain to fix this.

@dnbucklin
Copy link
Contributor

dnbucklin commented Sep 26, 2023

@rsbivand Thanks for the update. We have found a new maintainer (@Cidree), and the current plan is to release an update to address this soon. #28

@rsbivand
Copy link
Author

rsbivand commented Oct 9, 2023

@Cidree @dnbucklin @basille R spatial infrastructure packages maptools, rgdal and rgeos will be archived by CRAN on Monday, October 16, 2023. Your package does not pass CMD check when these packages are not available. Expect your package to be archived by CRAN October 17-18 as CRAN checks feed through and your package fails, if not updated by Monday, October 16, 2023.

No grace period is anticipated, as you have had sufficient time to update your package to remove dependencies on maptools, rgdal and/or rgeos. It remains the case that many packages importing the raster package needlessly depend on retiring packages, as raster stopped using them a year ago.

@Cidree
Copy link
Owner

Cidree commented Oct 11, 2023

@rsbivand Thank you for reminding us. The dependencies on maptools, rgdal and rgeos are already removed, and we are fixing the last details. We hope the package will we submitted soon.

@dnbucklin
Copy link
Contributor

Closing, as this issue is addressed in rpostgis v1.5.

@rsbivand
Copy link
Author

Thanks for your cooperation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants