Skip to content

[R-pkg-devel] Is R-Forge dead?

5 messages · Kevin Coombes, Brian G. Peterson, Ben Bolker +2 more

Original
Kevin Coombes
# 
Hi,

I have been maintaining packages in R-Forge for many tears. Last week I 
sent an email to r-forge at r-project.org to report problems with the build 
process. It appears that any changes I have pushed to R-Forge over 
approximately the last two months have resulted in the package remaining 
in the "Building" state, even though the logs suggest that the package 
built successfully on both LINUX and Windows. (Also, four of the six 
affected packages only included changes to the man pages to clean up 
NOTEs from the R cmd checks on old versions at CRAN, where the new 
versions now happily reside.) I have received no response nor 
acknowledgement to my email to R-Forge.

Assuming that R-Forge has finally succumbed to the ravages of entropy, 
does anyone have advice on creating a git project that contains multiple 
R packages? (I really don't want to have to create 20+ new git projects, 
one per package).

Best,
 ?? Kevin
Brian G. Peterson
# 
Kevin,

I can't speak to whether R-Forge is dead, we migrated our projects to
github a long time ago.

The most straightforward answer for R packages in git repositories is
to use separate git projects.  we were even able to import the entire
SVN history and r-forge issue history to github for each of our r-forge
projects when we migrated. The only major complexity that I recall was
creating a table mapping svn contributors to github users (where
available).

If you want to do it all in one git repository, I strongly suggest that
you *still* import all the svn history, but that you do it in one
directory per project, since this is required by `R CMD build`.  We
sometimes use this 'one package per directory' approach in some of our
private repositories at work.  In this case, if you use an IDE like
RStudio, you'll still create separate *RStudio* projects in each
directory, so that you can build, install, test, etc each package from
the IDE, but you can use a single repository for all of it.

Your future self will thank you for having full version control history
of all the "Olde" (tm) versions.

Best of luck.  - Brian

see reference below about importing an svn repo to git:


Ref:
https://docs.github.com/en/migrations/importing-source-code/using-the-command-line-to-import-source-code/importing-a-subversion-repository
Ben Bolker
# 
I don't know about R-forge, but it's perfectly workable to put 
multiple packages within a single repo, with each package in its own 
subdirectory.  You'll run into some headaches occasionally with (e.g.) 
CI machinery that assumes that the head of a git repo is also the 
primary package directory (e.g. 
https://github.com/r-hub/rhub/issues/584) ...
On 2024-07-01 6:04 p.m., Kevin R. Coombes wrote:
Duncan Murdoch
# 
While you can put multiple packages in one Git repository, I'd suggest 
that you don't do that.  Most packages are in their own repository, and 
that means that users who want to contribute to your packages are 
familiar with that setup.  If they have to fork 20 packages at once to 
make a contribution to one of them, they are less likely to want to do it.

Duncan Murdoch
On 2024-07-01 6:04 p.m., Kevin R. Coombes wrote:
Jeff Newmiller
# 
I cannot/will not to help you do this, but there are people out there who disagree with me who put considerable effort into doing this... the search term you would need in order to find them is "monorepo". But please reconsider...  the whole point of putting code into separate packages is to isolate their internals to make them less interdependent... putting all of them into a monorepo can lead you to forget that users experience them as distinct units.
On July 1, 2024 3:04:40 PM PDT, "Kevin R. Coombes" <kevin.r.coombes at gmail.com> wrote: