On 28/03/2023 2:00 p.m., Henrik Bengtsson wrote:
A quick drive-by-comment: What if 'R CMD build' would have an option
to flatten R/ subfolders when building the tarball, e.g.
R/unix/a.R
R/windows/a.R
R/a.R
becomes:
R/00__unix__a.R
R/00__windows__a.R
R/a.R
? Maybe that would be sufficient for most use cases. The only thing
I can imagine is that source file references (e.g. in check NOTEs)
will be toward the latter and not the former.
If you are renaming a file (or merging multiple files, etc.) you can use
#line directives so that diagnostic messages refer to the original file.
Duncan Murdoch
Of course, one could write a 'build2' shell script locally that wraps
all this internally, so that one can call 'R CMD build2 mypkg', which
then creates a flattened copy of the package folder, and runs 'R CMD
build' on that. Prototyping that could be a good start to see what
such a solution will bring and what it breaks.
/Henrik
On Tue, Mar 28, 2023 at 6:24 PM Barry Rowlingson
<b.rowling...@lancaster.ac.uk> wrote:
The "good reason" is all the tooling in R doesn't work with subfolders and
would have to be rewritten. All the package check and build stuff. And
that's assuming you don't want to change the basic flat package structure -
for example to allow something like `library(foo)` to attach a package and
`library(foo.bar)` to attach some subset of package `foo`. That would
require more changes of core R package and namespace code.
As a workaround, you could implement a hierarchical structure in your file
*names*. That's what `ggplot2` does with its (...downloads tarball...) 192
files in its R folder. Well mostly, there's a load of files called
annotation- and geom- and plot- and position- and stat- etc etc. No reason
why you can't have multiple "levels" separated with "-" as you would have
multiple folder levels separated with "/". You can then do `ls geom-*` to
see the `geom` "folder" and so on (on a unix shell).
And then when R Core receive a patch that implements subfolders, a quick
shell script will be able to create the hierarchy for you and drop all the
files in the right place.
One reason for the flat folder structure may be that R's packages
themselves have no structure to the functions - compare with Python where
modules can have subfolders and functions in subfolders can be access with
module.subfolder.subsub.foo(x), and module subfolders can be imported etc.
The whole module ecosystem was designed with structure in mind.
I don't think there's any restriction on subfolders in the "inst" folder of
a package so if you have scripts you can arrange them there.
Given that most of my students seem to keep all their 23,420 files in one
folder called "Stuff" I think we can manage like this for a bit longer.
B
On Tue, Mar 28, 2023 at 4:43 PM Antoine Fabri <antoine.fa...@gmail.com>
wrote:
This email originated outside the University. Check before clicking links
or attachments.
Dear R-devel,
Packages don't allow for subfolders in R with a couple exceptions. We find
in "Writing R extensions" :
The R and man subdirectories may contain OS-specific subdirectories named
unix or windows.
This is something I've seen discussed outside of the mailing list numerous
times, and thanks to this SO question
https://stackoverflow.com/questions/14902199/using-source-subdirectories-within-r-packages-with-roxygen2
I could find a couple instances where this was discussed here as well,
apologies if I missed later discussions :
* https://stat.ethz.ch/pipermail/r-devel/2009-December/056022.html
* https://stat.ethz.ch/pipermail/r-devel/2010-February/056513.html
I don't see a very compelling conclusion, nor a justification for the
behavior, and I see that it makes some users snarky (second link is an
example), so let me make a case.
This limitation is an annoyance for bigger projects where we must choose
between having fewer files with too many objects defined (less structure,
more scrolling), or to have too many scripts, often with long prefixed
names to emulate essentially what folders would do. In my experience this
creates confusion, slows down the workflow, makes onboarding or open source
contributions on a new project harder (where do we start ?), makes dead
code easier to happen, makes it harder to test the rights things etc...
It would seem to me, but I might be naive, that it'd be a quick enough fix
to flatten the R folders not named "unix" or "windows" when building the
package. Is there a good reason why we can't do that ?
Thanks,
Antoine
PS:
Other SO Q&As:
https://stackoverflow.com/questions/33776643/subdirectory-in-r-package
https://stackoverflow.com/questions/18584807/code-organisation-in-r-package-development
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
