[Rd] [External] subfolders in the R folder

[Henrik Bengtsson]

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.

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.rowlingson using 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.fabri using 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 using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel