Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrap some methods directly in R #152

Open
zouter opened this issue Apr 2, 2019 · 6 comments

Comments

@zouter
Copy link
Member

commented Apr 2, 2019

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

Current shortlist:

  • Slingshot
  • SCORPIUS
  • Monocle 3
@rcannood

This comment was marked as off-topic.

Copy link
Member

commented Apr 2, 2019

y tho

@rcannood

This comment has been minimized.

Copy link
Member

commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Apr 9, 2019

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

This comment was marked as off-topic.

Copy link
Member Author

commented Apr 10, 2019

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! 😁

@zouter zouter added this to the v1.1.0 milestone Apr 10, 2019

@zouter zouter self-assigned this Apr 10, 2019

zouter added a commit to dynverse/ti_scorpius that referenced this issue Apr 10, 2019

@zouter

This comment has been minimized.

Copy link
Member Author

commented Apr 10, 2019

@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 r_function 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_test_data.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

This comment has been minimized.

Copy link
Member Author

commented Apr 17, 2019

dyntoy is now in suggests, which cleans up the testing quite a bit! dynverse/ti_scorpius@0cc4d8a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.