Hi everybody,
I would like to take a minute to address the language used in the initial
e-mail, notably the "newbie/luser" terminology.
It was given in both the subject (" Two (newbie/luser) questions") as well
as the body ("... robust R package that might be useful (mainly to R
newbies/lusers of even lower R/programming skills than mine).").
Personally I find the term "luser" (as of a "loser user") very
condescending, whether it is about yourself (because you are not an
experienced programmer) or others (because you perceive them as
inexperienced programmers).
To put it short, using such a condescending term inhibits yourself and,
especially, others. Its use is simply unwarranted. Using the term about the
users of your package, regardless of their experience, is derogatory.
If you are writing to this mailing list with issues developing an
R-package, you are neither a newbie nor a loser, and we collectively will
do our best to help you. So no need in derograting yourself.
Kind regards,
Stefan
Den tir. 16. mar. 2021 kl. 14.05 skrev Chris Evans <chrish...@psyctc.org>:
> Hugely appreciated Duncan.
>
> ----- Original Message -----
> > From: "Duncan Murdoch" <murdoch.dun...@gmail.com>
> > To: "Chris Evans" <chrish...@psyctc.org>, "r-package-devel" <
> r-package-devel@r-project.org>
> > Sent: Tuesday, 16 March, 2021 10:48:50
> > Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI
> to github hosted package
>
> > On 16/03/2021 5:58 a.m., Chris Evans wrote:
> >> I would be very grateful of help as I seem to be making very heavy
> weather of
> >> all the intricacies of creating a
> >> robust R package that might be useful (mainly to R newbies/lusers of
> even lower
> >> R/programming skills than mine).
> >>
> >> I am making a lot of progress and am awed by the work so many have put
> in to
> >> make things possible: huge gratitude
> >> to too many to name. However, I seem to be hitting a wall on adding CI
> to my
> >> package.
> >>
> >> 1) I am sure that linting my package will help me but there are some
> defaults in
> >> lintr/superlinter that I am want
> >> to take a personal stand and not use: allowing myself not always to use
> perfect
> >> camelCase because I think it will
> >> confuse my end users and the line length limit which at the default of
> 80 seems
> >> to me, on a modern set up, to make
> >> my code far less readable than if I allow some long lines. My problem
> is that I
> >> am failing to work out how to override
> >> the defaults. I thought that putting in /TEMPLATES/.lintr in my package
> >> directory and having it contain:
> >>
> >> # linters: with_defaults(object_usage_linter = NULL)
> >> linters: with_defaults(
> >> line_length_linter(120),
> >> cyclocomp_linter(25),
> >> object_name_linter = NULL
> >> )
> >> would override the defaults (I'm working on the cyclocomp complaint!)
> Can
> >> anyone, perhaps looking at my
> >> https://github.com/cpsyctc/CECPfuns/ package, tell me what I'm doing
> wrong and
> >> how to get it right?!
> >
> >
> > I use lintr, and put my .lintr file in the main directory of the package.
>
> OK. I have removed the TEMPLATES directory and moved .lintr to the
> package root.
>
> I think I am better keeping lintr local and having moved .lintr using
>
> lintr::lint_package()
>
> locally is working fine, flagging up cosmetics I can see are all
> improvements so I
> can sort those out without wasting github power. Which takes to the next
> stage ...
>
> >
> >
> >>
> >> 2) I work on a machine running Ubuntu 20.04 in Rstudio and everything
> checks and
> >> tests fine there but I wanted
> >> to use the github actions to check the package out on Windows and Mac
> and,
> >> rather more by luck I think than really
> >> understanding how I got there, I seem to have achieved that. Rather
> bizarrely,
> >> the code (it's only R source)
> >> passes on Windows and Mac but fails in the Ubuntu test systems with
> errors like:
> >>
> >> ── R CMD build
> ─────────────────────────────────────────────────────────────────
> >> * checking for file ‘.../DESCRIPTION’ ... OK
> >> * preparing ‘CECPfuns’:
> >> * checking DESCRIPTION meta-information ... OK
> >> * installing the package to process help pages
> >> -----------------------------------
> >> * installing *source* package ‘CECPfuns’ ...
> >> ** using staged installation
> >> ** R
> >> ** inst
> >> ** byte-compile and prepare package for lazy loading
> >> Error in dyn.load(file, DLLpath = DLLpath, ...) :
> >> unable to load shared object
> >> '/home/runner/work/_temp/Library/stringi/libs/stringi.so':
> >> libicui18n.so.55: cannot open shared object file: No such file or
> directory
> >> Calls: <Anonymous> ... namespaceImport -> loadNamespace ->
> library.dynam ->
> >> dyn.load
> >> Execution halted
> >> ERROR: lazy loading failed for package ‘CECPfuns’
> >>
> >> I _think_ these are just changes in the stirngi package that seem to
> failing on
> >> the test machine
> >> and OK on my machine. That made me think that I can see a lot of logic
> in my
> >> checking things on
> >> the various default versions of R in Ubuntu 16.04, Windows and MacOS
> but perhaps
> >> it is unnecessary
> >> and wasting resources to check the release version of R on Ubuntu 20.04
> as it
> >> seems safe enough to
> >> assume that the package built on my local machine in the release
> version of R
> >> and on Ubuntu 20.04
> >> that fails like this will only be transient (or that successes on my
> machine
> >> will only be ... but
> >> at least I'll see them and not waste github resources!)
> >>
> >> The catch is that I am baffled by how to configure github actions to
> change the
> >> lint defaults and
> >> to change the selection of releases and platforms. I think that may
> because I
> >> may have created
> >> a mess in my github actions workflows.
> >>
> >> Would anyone be willing to help or even to look at it and point me to
> the
> >> explanations I am failing
> >> to find?!
> >
> > You have 5 workflows, and their current content doesn't appear to match
> > the results on your actions page. Pick one, run it, and I'll see if I
> > can spot the reason for a failure.
>
> That is so appreciated Duncan. One stupid question: is there a way to run a
> workflow other than by making an upload/push (or a pull request)?
>
> I think I have discovered that the workflows are controlled by the yaml
> files
> in .github/workflows so I have deleted all except R-CMD-check.yaml and I
> think
> that when I now commit and push this that should delete the other
> workflows
> on github and trigger this one to run. If you could look at that one then
> that would be hugely appreciated. I see it says:
>
> strategy:
> fail-fast: false
> matrix:
> config:
> - {os: macOS-latest, r: 'release'}
> - {os: windows-latest, r: 'release'}
> - {os: windows-latest, r: '3.6'}
> - {os: ubuntu-18.04, r: 'devel', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest";,
> http-user-agent: "R/4.0.0 (ubuntu-18.04) R (4.0.0 x86_64-pc-linux-gnu
> x86_64 linux-gnu) on GitHub Actions" }
> - {os: ubuntu-18.04, r: 'release', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> - {os: ubuntu-18.04, r: 'oldrel', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> - {os: ubuntu-18.04, r: '3.5', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> - {os: ubuntu-18.04, r: '3.4', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> - {os: ubuntu-18.04, r: '3.3', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>
>
> Some questions as I, I think, make some progress:
>
> 1) Why is windows-latest pointing at 3.6? I am on 4.0.4 locally for
> windows. I assume this is because I have copied or pulled in
> a template that is out of date. Can I just replace that '3.6' with
> 'release'
>
> 2) My guts say that at this point it is sensible for me to test against
> devel, release and oldrel but that after the next
> release I could stop testing against oldrel? Is that sensible?
>
> 3) I see tests against 3.3, 3.4 and 3.5 there for ubuntu 18.04 and no
> 20.04. Am I correct that I could replace the above
> with this:
>
> strategy:
> fail-fast: false
> matrix:
> config:
> - {os: macOS-latest, r: 'release'}
> - {os: windows-latest, r: 'release'}
> - {os: windows-latest, r: 'release'}
> - {os: ubuntu-18.04, r: 'devel', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest";,
> http-user-agent: "R/4.0.0 (ubuntu-18.04) R (4.0.0 x86_64-pc-linux-gnu
> x86_64 linux-gnu) on GitHub Actions" }
> - {os: ubuntu-18.04, r: 'release', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> - {os: ubuntu-18.04, r: 'oldrel', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> - {os: ubuntu-20.04, r: 'devel', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
> - {os: ubuntu-20.04, r: 'release', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
> - {os: ubuntu-20.04, r: 'oldrel', rspm: "
> https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
>
> [I have changed the windows '3.6' to 'release' and the last three ubuntu
> calls to 20.04 and the R versions to 'devel', 'release'
> and 'oldrel' and the repositories to point at xenial not bionic. I have
> only done this here in the Email, not on disc!]
>
> It would be nice to check all that occasionally but I am sure that at the
> frequency I'm pushing up new functions and tweaks,
> so my colleagues can check things, I am putting far too much work on
> github with all those. Could I just check windows
> and macOS release and devel by commenting out lines there. Or is it
> better to have different yaml files and just to put
> the one you want in .github/workflows for each particular push? No great
> difference?
>
> OK. I have pushed these changes with the commit comment "More work to get
> continuous integration testing ..." and the
> actions seem to be running and I seem to have succeeded in pruning things
> down to that one action.
>
> Wonderful if you can find the time to have a look at these questions and
> the run ... now I'm off to the dentist.
> Hm: dentist ... bad day with R ... dentist ... OK, I'll take bad day with
> R any day!
>
> Thanks (and to all),
>
> Chris
>
> >
> > Duncan Murdoch
>
> --
> Small contribution in our coronavirus rigours:
>
> https://www.coresystemtrust.org.uk/home/free-options-to-replace-paper-core-forms-during-the-coronavirus-pandemic/
>
> Chris Evans <ch...@psyctc.org> Visiting Professor, University of
> Sheffield <chris.ev...@sheffield.ac.uk>
> I do some consultation work for the University of Roehampton <
> chris.ev...@roehampton.ac.uk> and other places
> but <ch...@psyctc.org> remains my main Email address. I have a work web
> site at:
> https://www.psyctc.org/psyctc/
> and a site I manage for CORE and CORE system trust at:
> http://www.coresystemtrust.org.uk/
> I have "semigrated" to France, see:
> https://www.psyctc.org/pelerinage2016/semigrating-to-france/
>
> https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/
>
> If you want an Emeeting, I am trying to keep them to Thursdays and my
> diary is at:
> https://www.psyctc.org/pelerinage2016/ceworkdiary/
> Beware: French time, generally an hour ahead of UK.
>
> ______________________________________________
> 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
