Closed schloerke closed 10 months ago
After typing all this out, I am understanding it as it should be an easy way for devs to declare what packages are being used. While using packages
as a string in the GHA workflow, those values are hidden away from the repo. Therefore, we should keep packages
as a filename whose file contents contain the packages being used.
It still leaves the questions
For
build-wasm-packages
'spackages
input parameter, I am wondering what the underlying motivation for using a new/unfamiliar file format.
The current one-line-per-entry text format for the packages
file is simply legacy from when we first started experimenting with building R packages for Wasm. Originally the process was powered by shell scripts, where using that kind of file as input makes a lot of sense.
I am not opposed to changing the format. In fact, I really like the idea to match setup-r-dependencies
, where the relevant data is in the GHA workflow file and DESCRIPTION
. Consistency is good and enables knowledge transfer for current users of r-lib/actions
. So, my vote would be to indeed move towards that model.
The only issue I see is that I'd still like to be able to use this workflow in a kind of meta-repo, one without an R package or DESCRIPTION
file in it. Under that use case, I still see the benefit of a flat text file. I think a yaml
file would be fine. Another format I considered was renv
lock files. However, I believe it should be possible to specify packages easily when writing such files by hand, and so I steered away from the lock file format.
Will there ever be any more information?
I am unsure, perhaps the intended webR version or R version would be useful? In the future we could use tagged r-wasm/webr Docker containers to build packages for a specific version of webR.
Note that, currently, package list entries are passed to rwasm::add_list()
. This supports pkgdepnds style package references, which are already fairly expressive so extra information such as specific package source and versioning can be encoded. I think things like deps::.
should also work.
Either way, switching to yaml would future-proof these files in a nice way for if/when we do want to track [web]R versions or other information. I would be OK with that.
Right, so what do you think about the following plan?
First, we switch around build-wasm-packages
so as to match setup-r-dependencies
behaviour:
Add the needs
parameter and automatically search for Config/Needs/[needs]
in the DESCRIPTION
file for packages.
Change packages
to take in text. Default to something like deps::.
or file::.
so that "this" package is installed by default. Ensure such references work with rwasm::add_pkg()
as expected.
Add an extra-packages
text field.
The above three package lists should be combined into an character R vector and passed to rwasm::add_pkg()
, rather than using add_list()
like currently.
In addition, we handle the case where there is no DESCRIPTION
file in the repo and it's more like a meta-package:
Tweak rwasm::add_list()
to work by taking in a yaml file and parsing it for a list of packages. Otherwise, it works as before. Perhaps we also rename it to rwasm::add_yaml()
or something similar.
Ensure that the action still works when there is no DESCRIPTION
file to be read for Config/Needs/wasm
.
If packages
is a single line and ends in .yml
, change behaviour so as to pass the given filename to rwasm::add_list()
. This will match current behaviour, and the special case should be documented clearly.
For
build-wasm-packages
'spackages
input parameter, I am wondering what the underlying motivation for using a new/unfamiliar file format.I'm not against it, just want to understand it.
Currently,
r-lib/actions
'ssetup-r-dependencies
has three locations to where it will look for packages to install.It will look for
Config/Needs/<NEEDS>
via theneeds
parameter.packages
is a default that hardly anyone sets manually because in the context of checking an R package, this field should not be changed. (You will typically always want to installdeps::., any::sessioninfo
extra-packages
is used by authors who do not want to clutter their DESCRIPTION file or for one-off changes.If possible, I'd like to leverage
r-lib/actions
existing approach.If
r-wasm/actions
is to be used within R packages, then I'd like to utilize the DESCRIPTION'sConfig/Needs/wasm
field as the typical entrypoint, with a backup ofpackages
orextra-packages
.If
r-wasm/actions
is to be used within a localized wasm-friendly CRAN repo, thenpackages
file is a great choice for providing information.If using a
packages
file, should it ever contain more fields such asdescription
orR version
or any other meta data? If so, should we upgrade the file to a yaml (to support comments) or DCF file (similar to the DESCRIPTION file)?