On 2023-01-08 1:38 p.m., Spencer Graves wrote:


On 1/8/23 11:36 AM, Kevin Coombes wrote:
I have been using R-Forge for many years for package development. And I have been using GitLab for other projects almost as long.

However, over the past few months, the R-Forge support seems to be decaying, and I now have several projects that won't currently build there because of various items that appear to need fixing at their end. So, I am actively exploring what it will take to move packages and projects to git.


      R-Forge was wonderful for me when I started using it.  Then several years ago, I started having problems like you described.  A few years ago I migrated from R-Forge to GitHub.


      One problem I encountered in the transition:  On R-Forge, I had multiple packages in the same R-Forge project.  I had to split them apart for GitHub.


I already know how to use a git client to clone a Subversion repository from R-Forge (using "git svn"). And how to change the remote origin to push it to a new git location. (And I  may also be willing to lose the revision history if it is going to make the transition easier.)

I am now at the step of understanding the recent changes at GitLab with respect to support for "Educational" or "Open Source" status, especially in terms of how many monthly minutes of CI/CD time I can use for free. When working on a new package, I tend to make lots of small commit-pushes, and it sounds like each one of those will eat up minutes. So, any advice on how to manage that issue would be greatly appreciated.


      When I first got into Subversion, I remember Doug Bates saying, "Commit early and often."  The word "Commit" doesn't mean the same in Git as in Subversion, so I would encourage you to "Git push early and often."


      There may be limits on free use of GitHub, but I'm not aware of them:  If you want a private account, you need to pay for that, but the charges for that are not much.

The free tier of Github allows 2000 minutes/month of continuous integration testing for private repos, and unlimited (???) for public repos. (2000 minutes/month is more than I've ever needed.)

Furthermore, it's pretty easy to set up github actions so that it only runs tests if you ask it to (by appending e.g. "[run ci]" to your commit message), or in opt-out mode (i.e., skip tests if "[skip ci]" is in your commit message).



      If anyone knows anything different from what I've just said, I hope they will disabuse my of this part of my ignorance.


       Spencer


Best,
   Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves <spencer.gra...@effectivedefense.org <mailto:spencer.gra...@effectivedefense.org>> wrote:

               If you use GitHub, I highly recommend using "GitHub
    Action" as
    described by Wickham and Bryan, R Packages:


    https://r-pkgs.org/code.html#code-style
    <https://r-pkgs.org/code.html#code-style>


               I'm not sure the best way to get it set up, but I have
    all my
    packages on GitHub configured so each "push" that changes anything has
    "R CMD Check" run on 5 different platforms:  The release version of
    R on
    the latest Windows, macOS, and Ubuntu plus the development version and     the most recent old release on Ubuntu.  I rarely run R CMD check on my
    local machine anymore:  I just "git commit" and "git push".  Then
    GitHub
    Action manages testing on those 5 platforms.


               To be precise, I do "git status" before "git push" to
    make sure I
    have "committed" everything I want to commit before I "git push".     And I     do "git pull" to make sure a collaborator hasn't "pushed" something new
    I should look at before I "git push".


               Finally, I want to thank again Gábor Csárdi who helped me
    greatly get
    past problems I hand with "GitHub Action" for my "sos" package.  He
    provided example workflows in:


https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml <https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml>


               I also needed LaTeX support, for which Gábor suggested
    the following:


    https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages
<https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages>


               Spencer Graves


    On 1/8/23 9:11 AM, Kevin R. Coombes wrote:
     > A very helpful answer. For some reason (probably because I have an
     > ancient perl script that automates the steps i take when building
    and
     > checking packages), I keep forgetting that the "tools" package
    let's me
     > do these things from within R.
     >
     > I had already isolated the offending line ("plot(obj)") inside
    the chunk
     > where the error occurred, and removed any additional arguments. I
     > wrapped that line in a "try" command followed by a conditional
     > "traceback()" to find the problem.  This allowed the package
    build to
     > knit the vignette and provide some feedback about what was going
    on. It
     > turned out that I had copied and pasted an assignment line of the
    form
     >
     > main <- [compute the title]
     >
     > from earlier in the code and pasted it directly as an argument to
    the
     > call to image.default. And R did exactly what I told it to (not
     > surprisingly), and interpreted the value of that assignment as the
     > unnamed "zlim" option that would have been the corresponding
    positional
     > argument that should have been there.
     >
     > And yes, I still use "left arrow" <- instead of equals = as
    assignments.
     > (Heck, I even use emacs and ESS with a leftover keybinding that
    uses the
     > underscore key to insert the left arrow. Apparently, I'm ancient
    myself.)
     >
     >    Kevin
     >
     > On 1/8/2023 5:04 AM, Duncan Murdoch wrote:
     >> On 07/01/2023 8:43 p.m., Kevin R. Coombes wrote:
     >>> Hi,
     >>>
     >>> I am in the middle of developing a new package, which contains a
     >>> markdown-knitr-html vignette. When I try to run
     >>>
     >>> R CMD build [mypackagedirectory]
     >>>
     >>> I get an error message
     >>>
     >>> Quitting from lines 330-336
     >>> Error: processing vignette  failed with diagnostics:
     >>> invalid z limits
     >>>
     >>> If I run the same markdown script interactively inside R
    Studio, there
     >>> is no error.
     >>> If I knit the markdown script inside R Studio, it produces the
    correct
     >>> HTML output, with no error.
     >>>
     >>> The offending lines of code (the chunk at 330-336) invoke an
    "image"
     >>> method on an object of a class defined in the package, which in
    turn
     >>> computes a matrix from items inside the object and calls
    image.default,
     >>> which is presumably where the error is coming from.
     >>>
     >>> Two questions: (1) How is it possible that the same code works
    error
     >>> free in the RStudio contexts, but fails in the attempt to build
    the
     >>> package?
     >>> (2) Any suggestions on how to debug something that only throws
    an error
     >>> from "R CMD build" would be most welcome.
     >>
     >> Debugging that sort of thing is hard.  Here's what I would try:
     >>
     >> From inside an R session, run
     >>
     >>   tools:::.build_packages("[mypackagedirectory]")
     >>
     >> That runs the code that R CMD build runs, so it might trigger
    the same
     >> error.  If so, debug in the usual way, with traceback(), etc.
     >>
     >> If that doesn't trigger the error, try it using a different
    front-end,
     >> e.g. running R at the command line instead of running it in RStudio.
     >>
     >> If you still can't trigger it, then start modifying the vignette to
     >> find the exact line that causes the error (e.g. by commenting
    out the
     >> second half of the code in that chunk; did the error go away?
    etc.).
     >> Then modify it again to save all the inputs to the bad line in a
    file
     >> before running it, and see if running that line in a different
    context
     >> still triggers the error. Etc.
     >>
     >> Duncan Murdoch
     >
     > ______________________________________________
     > R-package-devel@r-project.org
    <mailto:R-package-devel@r-project.org> mailing list
     > https://stat.ethz.ch/mailman/listinfo/r-package-devel
    <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

--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of working hours.

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to