hunzikp / velox

https://hunzikp.github.io/velox/
119 stars 23 forks source link

CRAN archive notification #43

Open jeffreyevans opened 4 years ago

jeffreyevans commented 4 years ago

Does anybody know how to contact the author of this package? He is being unresponsive to issue requests on GitHub and not responding to CRAN regarding check errors. CRAN maintainers are getting ready to archive the velox package from the repositories.

From CRAN "We have repeatedly asked for an update fixing the check problems with no reply from the maintainer thus far. Thus, package velox is now scheduled for archival on 2020-03-17, and archiving this will necessitate also archiving its strong reverse dependencies."

lbusett commented 4 years ago

@jeffreyevans I think here you can find a different email address and contact info:

https://icr.ethz.ch/people/hunziker/

it would be a pity to lose this package!

Lorenzo

lbusett commented 4 years ago

@jeffreyevans

No, forget about the previous message - most probably outdated. I now tried contacting the mainteiner on linkedin at:

https://www.linkedin.com/in/hunzikp/

, though unfortunately his contact info does not include an email address.

HTH

Jean-Romain commented 4 years ago

Does anybody knows what was the issue?

mikoontz commented 4 years ago

Here's the snapshot of the CRAN checks from just before the package was archived:

https://cran-archive.r-project.org/web/checks/2020/2020-03-17_check_results_velox.html

Jean-Romain commented 4 years ago

I could easily fix it. But if the maintainer is not responding this won't be useful.

mikoontz commented 4 years ago

Gotcha. Thanks for taking a look! Is there a means for someone else to take over maintainer duties, or does the original maintainer have to approve first?

Jean-Romain commented 4 years ago

We cannot submit a fix on CRAN for the maintainer. He could agree for transferring the role of maintainer to somebody else. But for that we need to get in touch with the current maintainer.

jeffreyevans commented 4 years ago

Hello all, I received a nice email from Philipp Hunziker (included below) regarding this issue. His current email is hunzikp@gmail.commailto:hunzikp@gmail.com. It sounds like he is not intending on maintaining the package any longer but, is more than willing to turn over maintenance to anybody that wants to take the package over. I should point out that I moved the velox dependency to the exactextractr (https://github.com/isciences/exactextractr and on CRAN) package which, not only benchmarks better than velox, but does not require any object coercion to a different object class. In the case of large spatial-temporal data I have found velox coercion to add quite a bit of overhead. The exactextractr package is intended for only extracting raster values and does not provide rasterization functionality. For this, I use the fasterize (https://github.com/ecohealthalliance/fasterize and on CRAN) package, which has also recently updated its C code to work under C++17 compiler requirements. Both of these packages require a sf class object but are easily coercible to sp classes using x <- methods::as(x, "Spatial").

Currently, the exactextractr package only operates on polygons but, I have had some correspondence with the developer and he is planning on adding support for points and lines. After benchmarking, we found that operating on the the raw value list object that exactextractr:: exactextractr outputs is much faster than using the internal function argument for outputting statistics. This is likely because we are using apply type functions and not for loops or operating in the tidyverse.

Best, Jeffrey Evans

Jeffrey S. Evans, Ph.D., | Senior Landscape Ecologist & Biometrician The Nature Conservancy | Protected Lands Science Visiting Professor | University of Wyoming | Zoology & Physology Laramie, WY | jeffrey_evans@tnc.orgmailto:jeffrey_evans@tnc.org | (970) 672-6766<tel:(970)%20672-6766>

Hi folks,

Hope you're doing well!

Sorry for not being on top of this sooner. As you might have guessed, I'm not actively maintaining velox anymore (and the gmail autofilter grouped these mails as a newsletter, so I just noticed them).

At this point we have two options: (1) I can try to get the code to a point where it passes the checks next weekend. Judging from the warnings this should be possible with reasonable effort, but I have very limited time on my hands, so there's a risk I won't make it before March 17th. (2) I'd be happy to give either of you co-ownership of the package and let you have a go at a fix. Let me know if you'd like to do that.

Cheers (and sorry again for the late reply!), Phil

On Tue, Mar 3, 2020 at 4:32 PM Kurt Hornik Kurt.Hornik@r-project.org<mailto:Kurt.Hornik@r-project.org> wrote: Dear maintainers,

This concerns the CRAN packages

GeNetIt amt spatialEco velox

maintained by one of you:

Jeffrey S. Evans jeffrey_evans@tnc.org<mailto:jeffrey_evans@tnc.org>: GeNetIt spatialEco Johannes Signer jsigner@gwdg.de<mailto:jsigner@gwdg.de>: amt Philipp Hunziker hunzikp@gmail.com<mailto:hunzikp@gmail.com>: velox

We have repeatedly asked for an update fixing the check problems shown on https://cran.r-project.org/web/checks/check_results_velox.html<https://cran.r-project.org/web/checks/check_results_velox.html> with no reply from the maintainer thus far.

Thus, package velox is now scheduled for archival on 2020-03-17, and archiving this will necessitate also archiving its strong reverse dependencies.

Please negotiate the necessary actions.

Best -k

Philipp Hunziker

From: Jean-Romain notifications@github.com Sent: Thursday, March 26, 2020 11:11 AM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)

We cannot submit a fix on CRAN for the maintainer. He could agree for transferring the role of maintainer to somebody else. But for that we need to get in touch with the current maintainer.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-604554600, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH74NCZLZV2FHID6NMYTRJOEA7ANCNFSM4LAOMD2Q.

Jean-Romain commented 4 years ago

I can fix it. Then he will only need to accept the PR resubmit the package.

cjcarlson commented 4 years ago

Hey @Jean-Romain did you happen to ever take this over? We have a bunch of scripts that are based on velox and I'm debating the effort to migrate them over versus just waiting a few weeks

Jean-Romain commented 4 years ago

I waiting for a validation from the author (or somebody in contact with him). I won't spent time on that if my PR won't be accepted because the author no longer check github and won't release the fix.

mikoontz commented 4 years ago

@cjcarlson: Can you install from GitHub and have it work, or are the failing CRAN checks relevant for your OS? (remotes::install_github("hunzikp/velox@master")) Is this COVID work and would you deem it critical? In which case I'll ask on your behalf whether @Jean-Romain might reconsider patching the package so it can at least be installed via his GitHub repository, but only if he has the bandwidth for it. Colin, please kibosh this request if I'm off base with it.

Jean-Romain commented 4 years ago

The problem is not a serious issue. It is a C++ compiler warning to protect against not fully explicit way to copy the memory. It does not affect the package itself. The code should be written differently but the code does what it is expected to do. So the package is still workable but the CRAN takes very seriously every warnings.

cjcarlson commented 4 years ago

Good news is (thank god) this isn't for COVID, no.

I've tried to install_github with devtools before and it's been failing. Hadn't thought to try using remotes, and sure enough, it looks like it works for now. Let me double-check whether it works across machines just as a precaution! But that was a good shout, thanks @mikoontz

jeffreyevans commented 4 years ago

I should point out that devtools has been split out into a few packages, remotes being one of them. The install_github in devtools is actually coming from remotes (where the function now lives). I have found that sometimes the function forwarding fails when called from devtools so, a good practice is the call the function directly from remotes.

Best, Jeff

Jeffrey S. Evans, Ph.D., | Senior Landscape Ecologist & Biometrician The Nature Conservancy | Protected Lands Science Visiting Professor | University of Wyoming | Zoology & Physology Laramie, WY | jeffrey_evans@tnc.orgmailto:jeffrey_evans@tnc.org | (970) 672-6766<tel:(970)%20672-6766>

From: Colin J. Carlson notifications@github.com Sent: Saturday, April 4, 2020 12:29 PM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)

Good news is (thank god) this isn't for COVID, no.

I've tried to install_github with devtools before and it's been failing. Hadn't thought to try using remotes, and sure enough, it looks like it works for now. Let me double-check whether it works across machines just as a precaution! But that was a good shout, thanks @mikoontzhttps://github.com/mikoontz

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-609070310, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH7ZQOITB5XHWWWQA3MDRK54AHANCNFSM4LAOMD2Q.

jeffreyevans commented 4 years ago

Sorry, strike that comment about install_github in devtools/remotes. In the current versions, it looks like they have now just replicated the function in both packages. Previously, calling install_github from devtools just passed the function arguments to remotes::install_github. Not sure why they changed it because Hadley is trying to split out specific functionality to each individual package rather than having devtools be a catch all. If you look at the two package calls they are the identical function devtools:: install_github or remotes::install_github

From: Colin J. Carlson notifications@github.com Sent: Saturday, April 4, 2020 12:29 PM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)

Good news is (thank god) this isn't for COVID, no.

I've tried to install_github with devtools before and it's been failing. Hadn't thought to try using remotes, and sure enough, it looks like it works for now. Let me double-check whether it works across machines just as a precaution! But that was a good shout, thanks @mikoontzhttps://github.com/mikoontz

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-609070310, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH7ZQOITB5XHWWWQA3MDRK54AHANCNFSM4LAOMD2Q.

cjcarlson commented 4 years ago

Huh! Maybe it's a machine difference. I'll keep tinkering, in that case.

lbusett commented 4 years ago

Another possibility is installing the archived CRAN version using devtools::install_version():

devtools::install_version("velox", version = "0.2.0")
hunzikp commented 4 years ago

Hey folks, package author and (former) maintainer checking in. Sorry for not being on top of this. @Jean-Romain if you'd be able to make the changes to ensure we can reupload to CRAN, that'd be amazing. I'd also be more happy to give you authorship on the package. The same applies to anyone else wanting to pitch in. Since my email has already been posted here publicly, feel free to reach out: hunzikp [at] gmail [dot] com.

thiagoveloso commented 4 years ago

Just wondering: any advances on this issue?

jeffreyevans commented 4 years ago

This package is no longer being maintained and the author has moved on to other things. For fast raster extraction I would reccomend using the exact_extract function in exactextractr package.

Sent from Outlook Mobilehttps://aka.ms/blhgte


From: Thiago V. dos Santos notifications@github.com Sent: Monday, June 15, 2020 6:29:44 PM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)

Just wondering: any advances on this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-644459982, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH7ZAOQBZWWAA7AVMQT3RW24HRANCNFSM4LAOMD2Q.

thiagoveloso commented 4 years ago

This package is no longer being maintained and the author has moved on to other things. For fast raster extraction I would reccomend using the exact_extract function in exactextractr package. Sent from Outlook Mobilehttps://aka.ms/blhgte

Such a pity... I thought someone would take over the development/maintenance of the package.

Any recommendations for faster raster cropping/masking operations using polygons? raster is a good, reliable tool in like 95% of the times, but sometimes my workflow is really bottlenecked by its cropping/masking capabilities...

Jean-Romain commented 3 years ago

I made a PR to fix velox. See https://github.com/hunzikp/velox/pull/48

Jean-Romain commented 3 years ago

Bad new. The package was removed based on warning on Linux and Windows. The problems are gone on Linux but I checked on Windows and are still present. Troubleshooting are coming from boost and cannot be fixed easily. The code sounds legit and CRAN is maybe too aggressive on its check. Because it is not allowed to change compilation directives I don't think I can do anything. I suspect an issue with gcc 8 specifically