[R-pkg-devel] Best practices for a contributor who prefers to be cited only by their GitHub ID?
Hello, We recently started receiving contributions from a user who prefers to only use their GitHub ID. I tried this entry in DESCRIPTION (with their actual ID): person(comment=c(github="@github_user_id"), role="ctb") But R CMD check complains: * checking DESCRIPTION meta-information ... NOTE Authors@R field gives persons with no name: [ctb] (github: @github_user_id) Is this actually disallowed for the 'ctb' role, which does not appear in the package citation? I can see the need for more transparency around the 'cre', 'aut', and especially 'cph' roles. What is the best practice in this case? Should I just write fake names, or do we require the user to divulge a real name? I don't see this discussed in WRE or ?person. Michael Chirico __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] perl = TRUE fails on ubuntu
https://stackoverflow.com/questions/3796436/whats-the-technical-reason-for-lookbehind-assertion-must-be-fixed-length-in-r On Tue, May 27, 2025, 4:07 PM Josiah Parry wrote: > Hi all, > > I've encountered an issue where using `perl = TRUE` for regular expressions > with grepl() causes an error on ubuntu CI runners only. > > Is this a known limitation of perl = TRUE for grep and family in base R? Or > is there a suggested workaround? > > The issue is specifically with lookbehinds: > > PCRE pattern compilation error > 'lookbehind assertion is not fixed length' > at '(?<=(FeatureServer|MapServer)/)[0-9]+/?$' > > Any guidance would be very much appreciated! I'd like to avoid adding a > stringi dependency if possible. > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] perl = TRUE fails on ubuntu
Thanks all! Kevin, I think you make a really good point that the lookbehind isn't necessary. If I'm checking for the termination of /[0-9]+$ that is sufficient to know that the string ends with that pattern. On Tue, May 27, 2025 at 3:24 PM Kevin Ushey wrote: > Hi Josiah, > > Why not share a reprex / something we can copy and paste to directly > reproduce the issue? > > In any case, I suspect this depends on the underlying PCRE > implementation, and so isn't really directly an R issue. You might > have luck if you rewrite your regular expression from: > > (?<=(FeatureServer|MapServer)/)[0-9]+/?$ > > to something like (I didn't count parentheses below so assume I made a > mistake) > > (?:(?<=FeatureServer)|(?<=MapServer)))/)[0-9]+/?$ > > Or, alternatively -- does this really need to be a lookbehind? Can you > just match that text as-is and then capture whatever you happen to > find in front of it? > > Best, > Kevin > > On Tue, May 27, 2025 at 3:07 PM Josiah Parry > wrote: > > > > Hi all, > > > > I've encountered an issue where using `perl = TRUE` for regular > expressions > > with grepl() causes an error on ubuntu CI runners only. > > > > Is this a known limitation of perl = TRUE for grep and family in base R? > Or > > is there a suggested workaround? > > > > The issue is specifically with lookbehinds: > > > > PCRE pattern compilation error > > 'lookbehind assertion is not fixed length' > > at '(?<=(FeatureServer|MapServer)/)[0-9]+/?$' > > > > Any guidance would be very much appreciated! I'd like to avoid adding a > > stringi dependency if possible. > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] perl = TRUE fails on ubuntu
Hi Josiah, Why not share a reprex / something we can copy and paste to directly reproduce the issue? In any case, I suspect this depends on the underlying PCRE implementation, and so isn't really directly an R issue. You might have luck if you rewrite your regular expression from: (?<=(FeatureServer|MapServer)/)[0-9]+/?$ to something like (I didn't count parentheses below so assume I made a mistake) (?:(?<=FeatureServer)|(?<=MapServer)))/)[0-9]+/?$ Or, alternatively -- does this really need to be a lookbehind? Can you just match that text as-is and then capture whatever you happen to find in front of it? Best, Kevin On Tue, May 27, 2025 at 3:07 PM Josiah Parry wrote: > > Hi all, > > I've encountered an issue where using `perl = TRUE` for regular expressions > with grepl() causes an error on ubuntu CI runners only. > > Is this a known limitation of perl = TRUE for grep and family in base R? Or > is there a suggested workaround? > > The issue is specifically with lookbehinds: > > PCRE pattern compilation error > 'lookbehind assertion is not fixed length' > at '(?<=(FeatureServer|MapServer)/)[0-9]+/?$' > > Any guidance would be very much appreciated! I'd like to avoid adding a > stringi dependency if possible. > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] perl = TRUE fails on ubuntu
Hi all, I've encountered an issue where using `perl = TRUE` for regular expressions with grepl() causes an error on ubuntu CI runners only. Is this a known limitation of perl = TRUE for grep and family in base R? Or is there a suggested workaround? The issue is specifically with lookbehinds: PCRE pattern compilation error 'lookbehind assertion is not fixed length' at '(?<=(FeatureServer|MapServer)/)[0-9]+/?$' Any guidance would be very much appreciated! I'd like to avoid adding a stringi dependency if possible. [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] perl = TRUE fails on ubuntu
I believe the mysterious underused `regexec` is for this:
s = c("foo/bar", "baz/bur", "baz", "bar")
m = regexec("(foo|baz)/(b[au]r)", s)
regmatches(s, m) |> sapply("[", 3)
The `?regex` have some examples for parsing URL using regexec.
-- Jirka
On 28/05/25 10:24, Kevin Ushey wrote:
Hi Josiah,
Why not share a reprex / something we can copy and paste to directly
reproduce the issue?
In any case, I suspect this depends on the underlying PCRE
implementation, and so isn't really directly an R issue. You might
have luck if you rewrite your regular expression from:
(?<=(FeatureServer|MapServer)/)[0-9]+/?$
to something like (I didn't count parentheses below so assume I made a mistake)
(?:(?<=FeatureServer)|(?<=MapServer)))/)[0-9]+/?$
Or, alternatively -- does this really need to be a lookbehind? Can you
just match that text as-is and then capture whatever you happen to
find in front of it?
Best,
Kevin
On Tue, May 27, 2025 at 3:07 PM Josiah Parry wrote:
Hi all,
I've encountered an issue where using `perl = TRUE` for regular expressions
with grepl() causes an error on ubuntu CI runners only.
Is this a known limitation of perl = TRUE for grep and family in base R? Or
is there a suggested workaround?
The issue is specifically with lookbehinds:
PCRE pattern compilation error
'lookbehind assertion is not fixed length'
at '(?<=(FeatureServer|MapServer)/)[0-9]+/?$'
Any guidance would be very much appreciated! I'd like to avoid adding a
stringi dependency if possible.
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
