Pull from stable/zenodo

[jwokaty]

We should change so that we pull data from stable (zenodo) or the bleeding edge as we currently do. Add an argument stable = TRUE to pull from zenodo.

[lgeistlinger]

Hi @jwokaty: would you be ready for going ahead with adding this feature to bugsigdbr::importBugSigDB after the release to zenodo? Thanks!

[jwokaty]

@lgeistlinger Should the default option be to pull from the edge since that's how it currently works? Or should the default be stable = TRUE to pull from Zenodo?

[lgeistlinger]

Or should the default be stable = TRUE to pull from Zenodo?

Yes, pulling the stable release from zenodo should become the default.
Maybe better to call the argument version, as we will have different release versions in the future. Eg there might be a 2.0 release at some point in the future, and people might still want to pull the 1.0 release for reasons of comparability.

For the time being, I would imagine version = "1.0.1" being the default (likely one could also support version = "1.0.0" to pull your pre-release?), and version = "devel" to pull from the edge.

[jwokaty]

@lgeistlinger Should we use the DOI instead of the version number as suggested by @lwaldron? While version numbers are easy to remember, DOIs are citable and automatically resolvable.

[lgeistlinger]

Sounds like a good idea!

[lwaldron]

rather than a stable=TRUE argument, perhaps this should be a version = argument, with possibilities:

• a Zenodo DOI, e.g. 10.5281/zenodo.5819260 or URL, e.g. https://zenodo.org/record/5819260. Strictly speaking this should be updated with each release to ensure reproducibility, although for now we could use the "concept" DOI as a default to refer to the latest version, see below.
• devel (pull directly from bugsigdb.org)
• A github commit hash for BugSigDBExports, e.g. 30383a9 (note, this works the same as 30383a98f0159be83edb69afb259e4e21f13cd94 (lower priority, for people who want reproducible analysis but more recent than the last Bioconductor release)

Note, I considered also the following:

• release (default: pull from the latest Zenodo release, which is always 10.5281/zenodo.5606165 )
  But this seems to be frowned upon and will not in the future be supported by Zenodo, see "Where does the Concept DOI resolve to?" at https://help.zenodo.org/#versioning:

Currently the Concept DOI resolves to the landing page of the latest version of your record. This is not fully correct, and in the future we will change this to create a landing page specifically representing the concept behind the record and all of its versions.

[lgeistlinger]

I like it. Maybe we can add more semantics by renaming direct to devel or latest, emphasizing that this is not part of a release / has not been reviewed, but maybe that will only be clear with reading the man page anyhow.

[lwaldron]

That's a nice idea, I updated the options above.

[jwokaty]

I just want to reconfirm what's the default version. Previously, @lgeistlinger and I discussed the most recent version on Zenodo as the default; however, the purpose of rethinking the version argument is to avoid manual mapping. In this case, devel seems like the best choice for the default. Does this sound good or does anyone have another suggestion?

[lgeistlinger]

Thanks for checking in on that. The default should be the latest stable release, so that a user that calls importBugSigDB without providing the version argument (and thus not necessarily thinks much about it) gets a reviewed and approved release.

If somebody would like to pull from the edge (version = "devel"), I would like this person to actively indicate that s/he knows what s/he is doing by accordingly setting the version argument.

In agreement with @lwaldron's message above the default should thus be the concept DOI (10.5281/zenodo.5606165), pointing to the latest stable release, although unfortunately this will involve some manual updating in the future it appears.

[lwaldron]

strictly speaking, we should not use the concept DOI for the same reason Zenodo will be changing the behavior of it, that it doesn't reproducibly point to a specific data artifact. Strictly speaking, the default should be the version DOI that we want associated with the version of the Bioconductor release, so that each major release of bugsigdbr is associated with a single version of the data. I put strictly in italics because it is extra maintenance for potentially unnoticeable benefit, but there are a couple situations where it could pay off:

• software and data are tied together by default, so if we ever changed the format of the data exports, it would not break previous versions of the software that are run with the default version argument
• analyses are reproducible by default and associated with the software package version, and remain reproducible by default as future versions of software + data are released

Alternatively, we could just include a message reminding the user what to specify in the version argument if they want the data fetched to be reproducible, then leave it to the user how to make their analysis reproducible. I am rather on the fence and it depends on whether one of you minds adding another task to your semi-annual release jobs.

[lgeistlinger]

Thanks for clarifying. So let us be pro-active and make 10.5281/zenodo.5819260 (version 1.0.1) the default, noticing that this will require manual updates once we have a new release, which we assume to happen every half a year.