Potential speedup from `cyclocomp` about lintr HOT 8 CLOSED

OK, no answer, so I'll fork the cyclocomp repo into my account. CRAN also asked me to update the maintainer email, so there'll be a new release as well.

from lintr.

a fork into r-lib makes sense to me...

I'm not sure who manages those, but I know xmlparsedata is a fork of the same author by @gaborcsardi, maybe he can offer some insight.

from lintr.

I see that cyclocomp was updated on CRAN and includes the PR mentioned at the beginning, so I'm closing this. Thanks @gaborcsardi !

from lintr.

Thanks, @etiennebacher, for the suggestion!

Yeah, I also feel like it would be great if we either fork the repo to r-lib and incorporate a number of pending PRs or just import the functionality to {lintr} (MIT licence allows this). {cyclocomp} is stable enough that moving its source code to {lintr} shouldn't lead to additional maintenance woes.

WDYT, @AshesITR, @MichaelChirico?

from lintr.

Small bump on this. I just tried on a real package that contains some large files (polars) and the timing for lint_package() went from 240 seconds to 174 seconds due to this simple PR in cyclocomp.

from lintr.

cc @hadley / @wch, what's the process for adopting a package like {cyclocomp} into the r-lib org?

I couldn't find any info about this poking around the org's GH page, nor does "r-lib.org" have its own page...

from lintr.

IMO the place to start is by emailing the maintainer of the package. If that works, we can transfer to cyclocomp r-lib and take over maintenance. The main r-lib restriction is that we (i.e. me + my team) have right of first refusal if the maintainer wants to stop maintaining, and similarly we'll guarantee maintenance (at least to the level of keeping on CRAN) for any package in r-lib.

from lintr.

I am still the maintainer of cyclocomp on CRAN, but just wrote to the current maintainer of the GH package. But let's wait for the reply.

from lintr.