On Fri, Jan 19, 2024 at 8:41 PM Protsak Andriy via R-package-devel
wrote:
>
> Hi all!
>
>
>
> My name is Andriy, and I’m a student at University of Alcalá, currently
> working on my final year project.
>
>
>
> I’m tasked with organizing the R packages developed by our university that
> are curre
Dear Andriy
I would second the advice that David and Ivan have already given.
I woouls also add that I suspect that most users search for packages by
functionality so you might want to study techniques for search engine
optimisation and then advise authors how to increase the visibility of
th
Hello Andriy and welcome to R-package-devel!
On Fri, 19 Jan 2024 14:34:25 +
Protsak Andriy via R-package-devel
wrote:
> to achieve this the initial focus is on exploring the possibility of
> renaming the packages so that they share a common prefix, making it
> easier for uses to locate them
Hi Andriy
Renaming the packages seems quite drastic. It’ll break existing code and
the packages’ dependencies, and any existing name recognition will be lost.
I’m also a bit sceptical that it will greatly affect discoverability: I
don’t think most users find packages by scrolling through the big
a
On Wed, 28 Sep 2022 05:19:06 -0400
Duncan Murdoch wrote:
> However, some users are package writers. Once their package is on
> CRAN, it can be really inconvenient for you to change the behaviour
> of internal functions that they use, because CRAN will object if your
> change breaks their te
On 27/09/2022 9:37 p.m., Rolf Turner wrote:
On Tue, 27 Sep 2022 07:43:03 +
Georgi Boshnakov wrote:
...functions, that are not meant to be called directly by users,
should be documented in a file named -internal.Rd.
This is one option, convenient in the use-case of the question. But
why
If you haven't settled on exactly which approach you want to use in
accomplishing the main goals of your exported package functions, then hiding
the gory details can make it easier to tell people later to sod off when you
decide those gory details functions should act different or use different
On Tue, 27 Sep 2022 07:43:03 +
Georgi Boshnakov wrote:
> >...functions, that are not meant to be called directly by users,
> >should be documented in a file named -internal.Rd.
>
> This is one option, convenient in the use-case of the question. But
> why export a function that you active
l accessible via '?').
Stating clearly that such functions are internal is also sensible.
Georgi Boshnakov
-Original Message-
From: R-package-devel On Behalf Of Rolf
Turner
Sent: 27 September 2022 02:38
To: Andrew Simmons
Cc: List r-package-devel
Subject: Re: [R-pkg-deve
On Mon, 26 Sep 2022 20:07:28 -0400
Andrew Simmons wrote:
> This issue isn't related to RStudio.
>
> The issue is that you're exporting an object without providing any
> documentation for it. It sounds like you don't want to export it, so
> you need to go to your NAMESPACE file and remove the p
This issue isn't related to RStudio.
The issue is that you're exporting an object without providing any
documentation for it. It sounds like you don't want to export it, so you
need to go to your NAMESPACE file and remove the part was export(r2). If
you do want to export it, then you need to docum
Hi there,
I am writing to aks your help for an issuue arising when I am writing my R
package using R studio 1.2.1335 as follows.
``checking for missing documentation entries ... WARNING
Undocumented code objects:
'r2'
All user-level objects in a package should have documentation entries."
The f
Hey all,
I am trying to submit my R package to CRAN. I have previously tested on
win-builder but was unsuccessful to pass without ERROR due to the window
system still runs on outdated version of perl - 5.8.8 (13 years ago).
My package contains a fatpacked perl script that relies on a self contain
13 matches
Mail list logo
