Re: [R-pkg-devel] Question about preventing CRAN package archival
G'day Jeff, On Wed, 02 Jun 2021 11:34:21 -0700 Jeff Newmiller wrote: Not that I want to get involved in old discussions :), but... > MIT is more permissive than GPL2, ... this statement depends on how one defines "permissive". MIT requires that you fulfil: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." (https://opensource.org/licenses/MIT) Whereas GPL 2 merely requires that you "[...] conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty [...]". Thus, arguably, GPL 2 is more permissive. > so there is a collision there. Well, luckily the FSF does not think that the MIT license is incompatible with the GPL license, though it finds the term "MIT license" misleading and discourages its use, see https://www.gnu.org/licenses/license-list.html Cheers, Berwin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Native pipe in package examples
G'day Duncon,
On Thu, 25 Jan 2024 11:27:50 -0500
Duncan Murdoch wrote:
> On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
[...]
> I think you're right that syntax errors in help page examples will be
> installable, but I don't think there's a way to make them pass "R CMD
> check" other than wrapping them in \dontrun{}, and I don't know a way
> to do that conditional on the R version.
I remember vaguely that 'S Programming' was discussing some nifty
tricks to deal with differences between S and R, and how to write code
that would work with either. If memory serves correctly, those
tricks depended on whether a macro called using_S (using_R?) was
defined. Not sure if the same tricks could be used to distinguish
between different versions of R.
But you could always code your example (not tested :-) ) along lines
similar to:
if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
## code that uses native pipe
}else{
cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}
> I would say that a package that doesn't pass "R CMD check" without
> errors shouldn't be trusted.
Given the number of packages on CRAN and Murphy's law (or equivalents),
I would say that there are packages that do pass "R CMD check" without
errors but shouldn't be trusted, own packages not excluded. :)
Cheers,
Berwin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Native pipe in package examples
On Thu, 25 Jan 2024 09:44:26 -0800
Henrik Bengtsson wrote:
> On Thu, Jan 25, 2024 at 9:23 AM Berwin A Turlach
> wrote:
> >
> > G'day Duncon,
Uups, apologies for the misspelling of your name Duncan. Fingers were
too fast. :)
[...]
> > But you could always code your example (not tested :-) ) along lines
> > similar to:
> >
> > if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
> > ## code that uses native pipe
> > }else{
> > cat("You have to upgrade to R >= 4.1.0 to run this example\n")
> > }
>
> That will unfortunately not work in this case, because |> is part of
> the new *syntax* that was introduced in R 4.1.0. Older versions of R
> simply doesn't understand how to *parse* those two symbols next to
> each other, e.g.
>
> {R 4.1.0}> parse(text = "1:3 |> sum()")
> expression(1:3 |> sum())
>
> {R 4.0.5}> parse(text = "1:3 |> sum()")
> Error in parse(text = "1:3 |> sum()") : :1:6: unexpected '>'
> 1: 1:3 |>
> ^
>
> In order for R to execute some code, it needs to be able to parse it
> first. Only then, it can execute it. So, here, we're not even getting
> past the parsing phase.
Well, not withstanding 'fortune(181)', you could code it as:
if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
cat(eval(parse(text="1:3 |> sum()")), "\n")
}else{
cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}
Admittedly, it would be easier to say "Depends: R (>= 4.1.0)" in the
DESCRIPTION file. :)
Cheers,
Berwin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problem with loading package "devtools" from CRAN.
G'day Rolf, hope all is well. On Mon, 29 Apr 2024 01:19:50 + Rolf Turner wrote: > Executive summary: > > > The devtools package on CRAN appears to be broken. > > Installing devtools from github (using remotes::install_github()) > > seems to give satisfactory results. I somehow have not shared this experience. But then I compile on my machines (Ubuntu 22.04.4) R and packages from source. For me the devtools package from CRAN seems to work fine with R 4.4.0 > [...] I thereby obtained what I believe is the latest version of R > (4.4.0 (2024-04-24)). Well, what happens if you start R and enter "R.version"? That should confirm whether you run R 4.4.0. :) If you run R 4.4.0 but previously ran R 4.3.x then you are running now a version with a new minor version number. AFAIK, there is no guarantee that at the interface level to compiled code R versions remain compatible when the minor version number changes. So on machines where I do not compile from source, I usually run "update.packages(checkBuilt=TRUE)" whenever I upgrade R on those machines, definitely if the upgrade involves a change in the major or minor version number. Did you try updating your packages? Well, you probably first want to find out where exactly the Debian R distribution installs additional packages (Dirk might help there), and it might be that you have to run either (or all) of: update.packages(lib="/usr/local/lib/R/site-library", checkBuilt=TRUE) update.packages(lib="/usr/lib/R/site-library", checkBuilt=TRUE) update.packages(lib="/usr/lib/R/library", checkBuilt=TRUE) though, by a short look at my Ubuntu machine, it may be that the last two locations are not writeable for you as user, and the first one only if you belong to the group "staff" as normal user on your machine. > A bit of web-searching got me to a post on github by Henrik Bengtsson, > which referred to the devtools problem. Could you provide a link? I could not find anything relevant. :) > However there seems to be a problem with the devtools package on > CRAN, which ought to be fixed. Or, perhaps, just that the interface to compiled code changed from R 3.6.x to R 4.4.0 and, hence, all packages that rely on compiled code must be reinstalled. Stay safe. Cheers, Berwin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problem with loading package "devtools" from CRAN.
G'day Rolf,
On Tue, 30 Apr 2024 01:21:15 +
Rolf Turner wrote:
> Previously I got an error message from
>
> install.packages("devtools",lib="/home/rolf/Rlib")
>
> but now of course I cannot reproduce it.
Presumably the install.packages() invocation did not produce an error
message but a subsequent "library(devtools)" did?
I am not sure how remotes::install_github() behaves. Are you using R
directly or via RStudio? RStudio redefines the behaviour of
install.packages() so I am not sure what would happen if you type that
command into an R session running in RStudio.
As far as I remember, R's install.packages(), as you would invoke it if
you used R directly, installs the requested packages and any of its
(Depends/Imports) dependencies if these dependencies do not exist in
your libraries. As devtool's dependencies must have existed on your
system, your command only re-installed devtools but none of the
dependencies.
And it must be one of the dependencies that uses compiled code and
created the problem, as a "packageDescription("devtools")" actually
shows "NeedsCompilation: no".
You should really execute an
update.packages(lib="/home/rolf/Rlib", checkBuilt=TRUE)
whenever you upgrade your R version, definitely when the upgrade
involves changing the major/minor version.
Cheers,
Berwin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] is Fortran write still strictly forbidden?
Hi Jisca,
On Wed, 8 May 2024 10:37:28 +0200
Jisca Huisman wrote:
> I like to use write() in Fortran code [...] But from 'writing R
> extensions' it seems that there have been quite a few changes with
> respect to support for Fortran code, and it currently reads:
>
> 6.5.1 Printing from Fortran
>
> On many systems Fortran|write|and|print|statements can be used, but
> the output may not interleave well with that of C, and may be
> invisible onGUIinterfaces. They are not portable and best avoided.
I am not aware that there were any recent changes regarding printing
from Fortran recently, or that it was every strictly forbidden (perhaps
it is for packages that are submitted to CRAN?). In fact, R-exts.texi
for R 1.0.0 states pretty much the same as what you quoted from the
current WRE manual:
@subsection Printing from Fortran
@cindex Printing from C
In theory Fortran @code{write} and @code{print} statements can be
used, but the output may not interleave well with that of C, and will
be invisible on GUI interfaces. They are best avoided.
Three subroutines are provided to ease the output of information from
Fortran code.
@example
subroutine dblepr(@var{label}, @var{nchar}, @var{data}, @var{ndata})
subroutine realpr(@var{label}, @var{nchar}, @var{data}, @var{ndata})
subroutine intpr (@var{label}, @var{nchar}, @var{data}, @var{ndata})
@end example
Cheers,
Berwin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Cannot submit package due to misspell note
G'day all, On Sat, 7 Apr 2018 10:00:36 +0100 David Sterratt wrote: > On the subject of spell-checking, to avoid false positives when I'm > checking the package, in the directory above the package directory I > create a file called .spell_ignore with one word per line, [...] > All the false positives still come through in the CRAN check, but it > makes checking easier for me. I mentioned to David that http://dirk.eddelbuettel.com/blog/2017/08/10/ could prove enlightening regarding false positives when spell checking R packages, but apparently forgot to CC that e-mail to the list. Best wishes, Berwin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Forbidden URLs?
G'day Spencer, On Sat, 9 Nov 2024 23:56:49 -0600 Spencer Graves wrote: > Searching for "forbidden" in "Writing R Extensions" or in a > web search has given me nothing. Probably the wrong place to look. :) These messages have nothing to do with writing extensions for R but with CRAN policies. So more relevant are: https://cran.r-project.org/web/packages/policies.html and https://cran.r-project.org/web/packages/URL_checks.html (latter linked from the former). Not sure what the current state is, but IIRC in the past some websites blocked requests for URLs during these checks as they thought a crawler/robot was accessing their site. As long as you are sure the URL is accessible under normal circumstances by all (most?) users it should be fine, you might just have to explain this in a note when submitting your package. Cheers, Berwin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
