brlauuu / motevowrapper Goto Github PK

Consider adding a CODE_OF_CONDUCT.md file with specifications for the community standards.
I usually use this one: https://www.contributor-covenant.org/version/1/4/code-of-conduct/

More info: https://www.contributor-covenant.org/ (seems like there is a newer version already).

I would suggest to hook this repo up to a code coverage measurement service (I use https://about.codecov.io/) and submit code coverage measurement there.
This can be divided into two tasks.

1. Use this package to run unit tests (defining the unittest engine) in the CI. This is essentially a wrapper package around unit testing packages(unittest, pytest, nose) that will additionally generate the line coverate report.
2. Submit the measurement to their website (also in the CI), according to their instructions.

I assume that what you have under motevowrapper/tests serves as unit tests for the whole project.
Well, let's see how many lines they cover ;)

They will also give you a fancy shield with a coverage % value, put it in the README as well!

Im looking through the README now and I would suggest a few changes:

• "installation" seems to be divided into two parts: at the top is how to install the package itself, further downstream how to install the dependency. They are separated by the info-section on MotEvo. I would suggest to reorganize to have the theory on top and then a full "installation" section. Logically speaking users first need to install MotEvo itself, only then your pkg, right?

• double-check the language, I noticed a few times missing "s" or "a" or "the"

• Parameter description can be found in the MotEvo source code..

  That link does not take me to any source code, just a website with multiple downloads...

• You can note two parameters were added, try_until_succeeding and verbose

  No, I really cannot note it, I do not think any user of your package would double-check MotEvo source code and notice which parameters where added. So I do not think it is important to mention.

• For more information on how to use all of MotEvo's options, please check out MotEvo source code

  Same thing here, this link is a website, not the source code.

• Visualizing site density per motif using MotevoWrapper

  This section needs elaboration and maybe an exmaple visualisation<?>

I see that you stick to major.minor.patch versioning scheme and release new versions of the package.
Thats good!

It would be additionally nice to set up a changelog in CHANGELOG.md file in the root directory, describing features in bullet points. Please take a look here.

Speaking about versioning stuff, I think you could automate the release with this package. That way based on your commits GH would create new releases and then the CI would pick that up and push to PyPI as well.
(But that is a separate issue from the changelog, if you decide to go for it feel free to separate them).

Also, take a look at this commit msg standard: https://www.conventionalcommits.org/en/v1.0.0-beta.2/

I would strongly suggest to move the test data out of the actual python package directory to a top-lvl dir test. Data live outside of the Python package directory, separated from the source code. The latter should contain only modules/subpackages/submodules.

I see that you use unittest framework. I'm sure it can be adjusted to another repo structure. Since I always use pytest I cannot help more...

Some info:

• https://realpython.com/python-modules-packages/
• https://realpython.com/python-testing/

I have some suggestions regarding the example notebook:

• I would change the directory name from doc to notebooks, since docs should be reserved for elements generated by Sphinx.
• The content of the example.ipynb requires much more information in markdown as well as output dataframes and visualisations.
• Bonus points: set up interactive notebook run with binder service. The issue here would be: how to get MotEvo available there<?> But I'm sure it can be done. Worst case you inject a magic cell with a bash command to download the binary?

In case MotEvo fails, output in the report file what happened.

Just in the same way as you build and upload the package to PyPI you could also set up a CI workflow that would upload to Anaconda Cloud (upon each release). I don't know if there is already a well-baked GitHub Action for that, but if not you could just specify the commands manually in the YAML yourself, setting your Anaconda username and passwd as repo secrets.

You may follow this tutorial: https://docs.conda.io/projects/conda-build/en/latest/user-guide/tutorials/build-pkgs.html

The only issue I can think of is that packages in anaconda usually contain all their dependencies...
So you would need to upload the MotEvo binary too...
Or you could hook it up to this package which would be a dependency.
This is sth to consider...

// Can be further automatized as in #7.

Add option for users to see report output from MotEvo run.

It is usually a good practice to have a top level CONTRIBUTING.md file which specifies instructions for other developers. The content is entirely up to you, feel free to google around. I just found this one.

I would suggest to introduce a CI workflow which could run a static code analysis for python scripts; flake8 is a popular linter for python. That way you would ensure that the code inside the repository complies with the community standards. You can find an example here. If you are overzealous like I am you may also use black formatter and introduce CI checks for it too (just like in the exapmle above) but that is not necessary. Remember that the behaviour of both tools you can customize to your liking with configfiles.

Such a CI workflow should, of course, contribute a nice shield to the README file. Black has its own shield too.

This isnt really anything to improve, just if you're bored and wanna learn new things / make the package cooler:

You could create a small docs website for the package and put all the specific info there.
There are two ways to go about this:

1. Use the ReadTheDocs service, take a look here: https://docs.readthedocs.io/en/stable/
2. Use the built-in GitHub Pages mechanism: set up CI to deploy your website into a separate branch and hook up Pages to that branch; see https://github.com/peaceiris/actions-gh-pages

The advantage of (1) is that you have all automatically set up for you, but it is external.
In case of (2) all is contained within this repo but you have to set it up yourself, so there is a tradeoff.
I personally favour (2).

Either way, read about Sphinx package to generate Python docs. I believe you could use it to generate a PDF version of the docs too...

I'd suggest to merge python-tests-mac.yml and python-tests.yml files into one.
GH Actions YAML syntax allow to execute CI workflows on multiple platforms (check here).
If you need to execute a command specifically to only one of the systems you can conditionalize on the runner specifications.

Edit:

If I see this correctly, currently both CI workflows run the unit testing framework<?>
So I would change the name of the (merged) GH shield to unit

MotEvo has in total 3 modes:

• Transcription Factor Binding Site predictions (TFBS)
• enchancer prediction (ENH)
• wm_refinement (WMREF)

At the moment, only support for TFBS is present. Support for other two modes is to be implemented.

There are several GitHub-specific text files which could help others interact with this repository: templates for issues and pull requests. It would be nice to add them here as well.

Take a look at how I set them up in one of my repos we develop in our group: bindz.
You need to add a top-level file: PULL_REQUEST_TEMPLATE.md as well as two files under .github/ISSUE_TEMPLATE. You may copy and use the same text as I do or adjust the contents to whatever you like.

Currently, tests are available only for TFBS. Tests need to be added for ENH (enhancer finding), or WMREF (weight matrix refinement).