dynverse / dynmethods

A collection of 50+ trajectory inference methods within a common interface 📥📤
https://dynverse.org
Other
118 stars 26 forks source link

Wrap some methods directly in R #152

Open zouter opened 5 years ago

zouter commented 5 years ago

We don't want to make this list too long, as this will make it hard to maintain in the long run.

Current shortlist:

rcannood commented 5 years ago

y tho

rcannood commented 5 years ago

Wouter and I discussed this in person; it's a good idea to have dynmethods support a few methods out of the box without having to install docker, though I think submitting cran should have a higher priority.

zouter commented 5 years ago

https://github.com/dynverse/dynmethods/tree/scorpius_package is a first attempt at doing this.

When a user runs ti_scorpius, it will give you a prompt asking whether you want to use the R wrapper or the docker wrapper. When choosing the R wrapper, the dynverse/ti_scorpius package will be installed and run using dynwrap::create_ti_method_r()

zouter commented 5 years ago

Wouter and I discussed this in person; it's a good idea to have dynmethods support a few methods out of the box without having to install docker, though I think submitting cran should have a higher priority.

Well I can't submit to CRAN if dynutils is not updated! :grin:

zouter commented 5 years ago

@rcannood

You can find an example at https://github.com/dynverse/ti_scorpius/tree/package

definition.yml and example.sh are symlinked. This seemed to me the cleanest way of putting these both in the root directory and the package directory.

The definition.yml contains a "package" section, which describes the package. The only place that this is really used is in dynmethods. In principle, the two values here are not necessary because (1) the remote package can be extracted in dynmethods by checking the git remote and (2) the rfunction can be assumed to have the name `ti[method_id]`.

Testing is included inside the package but this can be quite verbose because I don't want to depend directly dyntoy. So the example dataset is generated first using the _package/tests/generate_testdata.sh script which calls the package/inst/example.sh scripts which saves an hdf5 file inside package/inst/example.h5 which is used for testing. Not ideal, perhaps we should depend on dyntoy...

Otherwise, most things are pretty clean, e.g. the run.R directly calls the run function of the package, the version number is extracted from the DESCRIPTION, etc

Any recommendations @rcannood ?

zouter commented 5 years ago

dyntoy is now in suggests, which cleans up the testing quite a bit! https://github.com/dynverse/ti_scorpius/commit/0cc4d8a45a0e0671ab570974a40628de483221c6