-
Notifications
You must be signed in to change notification settings - Fork 40
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
adding scPRINT and its suite of packages #195
base: main
Are you sure you want to change the base?
Conversation
Hello, do you have any feedback on this? |
Sorry, I'm a bit behind on this due to vacation time. |
Hi @jkobject, thanks for submitting the packages. Overall, this looks good, my main concern is test coverage. According to our guidelines we require that
which is not the case for any of the packages. Really most/all functions of your public API should be covered and tests should ideally also test for correct outputs and not just that no Exception occurs. Other feedback
|
Hi @grst, Thanks for the feedback! I do understand that coverage should be maximal and will update the codes to test more files. Many files are actually barely used anymore and might be better removed I believe. For scPRINT, while I test the denoising pipeline and make sure that it is performing well. I might not be able to test the quality of the results as easily for the network inference, embedding, and classification part. But I will add tests rather than exceptions as much as I can. I will come back to you in a few weeks with the updates! Best, |
Name of the tool:
Short description:
How does the package use scverse data structures (please describe in a few sentences):
mandatory
Recommended
@scverse_team
) to include are:Footnotes
We recommend thtat tests cover at least all user facing (public) functions. Minimal tests ensure that the function does not fail on an example data set. Ideally, tests also ensure the correctness of the results, e.g. by comparing against a snapshot. ↩
Continuous integration means that software tests are automatically executed on every push to the git repository. This guarantees they are always run and that they are run in a clean environment. Scverse ecosystem packages most commonly use GitHub Actions for CI. For an example, check out our cookiecutter template. ↩
By API documentation, we mean an overview of all public functions provided a package, with documentation of their parameters. For an example, see the Scanpy documentation. In simple cases, this can be done manually in a README file. For anything more complex, we recommend the Sphinx Autodoc plugin ↩