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
1 of 3 tasks
zouter opened this issue Apr 2, 2019 · 6 comments
Open
1 of 3 tasks

Wrap some methods directly in R #152

zouter opened this issue Apr 2, 2019 · 6 comments
Assignees
Milestone

Comments

@zouter
Copy link
Member

@zouter zouter 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.

@rcannood
Copy link
Member

@rcannood rcannood 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.

Loading

@zouter
Copy link
Member Author

@zouter zouter 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()

Loading

@zouter

This comment was marked as off-topic.

@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
Copy link
Member Author

@zouter zouter 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 ?

Loading

@zouter
Copy link
Member Author

@zouter zouter commented Apr 17, 2019

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants