Upload Folders to Zenodo

Creates a Zenodo deposition for each folder, uploads every file in it, and attaches metadata. Designed to take the output of osf_file_download() directly, so a whole OSF account can be archived on Zenodo in two steps:

Usage

zenodo_upload(
  folders,
  sandbox = TRUE,
  zenodo_pat = NULL,
  publish = FALSE,
  license = "cc-by-4.0",
  upload_type = "dataset",
  metadata = NULL,
  as_zip = TRUE,
  split_materials = "materials",
  upload_osf_metadata = TRUE,
  max_file_size = NULL,
  ask = TRUE,
  pb = NULL
)

Arguments

folders

a data frame returned by osf_file_download(), or a character vector of paths to folders to upload (one deposition per folder)

sandbox

whether to upload to the Zenodo sandbox (the default) rather than the real zenodo.org

zenodo_pat

a Zenodo personal access token. Defaults to whatever zenodo_pat() returns for this server. See zenodo_pat() for how to create one.

publish

whether to publish each deposition. FALSE (the default) leaves it as a draft for you to check and publish by hand.

license

the Zenodo license identifier to use when the OSF project has no license Zenodo recognises

upload_type

the Zenodo resource type (e.g. "dataset", "publication", "software")

metadata

a list of extra metadata fields to add to every deposition, overriding what was taken from the OSF

as_zip

whether to upload each folder as a single ZIP archive instead of as individual files.

Zenodo has no folders. Its documentation says so directly – "Zenodo does not support uploading and organising files into folders/directories. Instead, you can create a ZIP archive and upload it, in which case Zenodo will display the file structure inside the ZIP" – and the API agrees: a file name containing "/" is rejected, and a file record has no path field.

So there is a choice. TRUE (the default) keeps the folder structure exactly, which is what an archive is for: a reader gets the project as the author arranged it, rather than a heap of files they must sort out. The usual objection – that reaching one small file means downloading everything – is what split_materials answers, by putting the bulky part in a separate archive.

FALSE uploads the files separately, which keeps each one visible, previewable and downloadable on its own; the folder structure is lost, though file names are kept short and only prefixed where two files would otherwise collide. That suits a small flat folder, where the structure carries no meaning worth preserving.

split_materials

which CATEGORIES of file to put in their own archive when as_zip = TRUE. Defaults to "materials", which is usually the bulk of a repository's size and the part a reader is least likely to need.

Categories are the same six repo_check() reports – data, code, materials, documentation, output, unknown – decided by the same classifier, so a file lands in the same category whether it is being checked or archived. Pass more than one to separate them further, for example c("materials", "output").

Every archive stores the same project folder at its root, so unzipping all of them rebuilds the original tree exactly, while unzipping only the main one gives everything except the split categories, each file still in its right place. That lets somebody take the data and code without a multi-gigabyte stimulus set.

Set NULL or FALSE for a single archive holding everything. Ignored unless as_zip = TRUE.

upload_osf_metadata

whether to upload the _osf_metadata folder that osf_file_download() saves inside each project – the wiki pages, the activity log, and the project record. TRUE by default, so the archive on Zenodo describes itself. Set FALSE to deposit only the data files; the metadata is still read either way, since that is where the deposition's title, licence and authors come from.

max_file_size

largest file to upload, in MB; larger files are skipped and reported. Set to NULL for no limit.

ask

whether to show a summary and ask for confirmation before uploading anything. Ignored in a non-interactive session, where the upload proceeds without asking.

pb

a progress bar passed from another function

Value

a data frame with one row per folder: the folder path, the Zenodo deposition id, its DOI, the URL to review it, how many files were uploaded and skipped, and whether it was published

Details

osf_file_download("4i578", download_to = "my_osf") |>
  zenodo_upload()

Safety

Uploads go to the Zenodo sandbox by default. The sandbox is a complete separate copy of Zenodo, run for testing at https://sandbox.zenodo.org. It has its own accounts and its own tokens, and the DOIs it mints use a test prefix that never resolves publicly, so nothing you do there is permanent. Set sandbox = FALSE only once a sandbox run looks right.

Depositions are left as unpublished drafts (publish = FALSE). A draft can be edited or deleted freely. Review each draft in your Zenodo account, then press Publish there when you are satisfied. Publishing on the real zenodo.org is irreversible: the record and its DOI are permanent and cannot be deleted.

Examples

if (FALSE) { # \dontrun{
# download one OSF project and put it on the sandbox as a draft
osf_file_download("6nt4v", download_to = "archive") |>
  zenodo_upload()

# upload a folder you already have
zenodo_upload("archive/6nt4v")

# once the sandbox run looks right, upload for real (still a draft)
zenodo_upload("archive/6nt4v", sandbox = FALSE)
} # }