py4cytoscape 0.0.11

Cytoscape Automation API

py4cytoscape

This project recreates the R-based RCy3 Cytoscape Automation library as a Python package. The idea is to allow a Cytoscape workflow to be written in one language (R or Python) and translated to another language (Python or R) without having to learn different Cytoscape interfaces. The previous Cytoscape Python interface (Py2Cytoscape) has different features than the Cytoscape R library, and is therefore deprecated.

Additionally, this project attempts to maintain the same function signatures, return values, function implementation and module structure as the RCy3, thereby enabling smooth maintenance and evolution of both RCy3 and py4cytoscape.

This project uses PyCharm because of its excellent code management and debugging features.

Over time, py4cytoscape functionality should match RCy3 functionality. Once that occurs, novel Py2Cytoscape functions will be added to both as appropriate. The official Automation API definition met by both RCy3 and py4cytoscape is here. The API is versioned, and you can see which API version RCy3 or py4cytoscape implements by executing the cytoscape_version_info() or cytoscapeVersionInfo() function.

An overall scorecard comparing Py2Cytoscape, RCy3 and py4cytoscape can be found here. Pay close attention to columns E and F, which show how much of RCy3 is reflected in py4cytoscape.

Documentation

To understand the API structure and see calling examples, see the py4cytoscape documentation.

How to install and test

For an explanation of py4cytoscape installation and testing, see the INSTALL.rst file.

How to run a simple workflow

For a quick tutorial on how to build a workflow in Python and using py4cytoscape, see https://py4cytoscape.readthedocs.io/en/latest/tutorials/index.html. You can try py4cytoscape with a web browser only, without installing anything in your local environment.

How to configure logging

py4cytoscape logging is based on the Python logging package, which is based on the Java logging framework.

For an explanation of log configuration and use, see the LOGGING.rst file.

How to build and release

1. Create a new release file in doc/release to match the version number (e.g., release_0.0.1.rst)
2. Update the theme list in doc/release_log.rst and reference the release file you just created
3. Update the version number in both py4cytoscape/_version.py and build.bat
4. If any API changes were made, be sure to update the Automation API Definition and change the Automation API version in py4cytoscape/_version.py
5. If any functions were added, be sure to add them to the appropriate .rst file in the References section of the document.
6. Verify that the requirements.txt file in the docs directory correctly identifies all external dependencies.
7. Verify that the setup.py file correctly identifies all external dependencies.
8. Verify that changes to the user manual are correct. Be sure to activate automatic ReadTheDocs building for this new version.
9. Check all sources (including documents and tests) into Github, merge them into the Master branch, and make Master the current branch
10. Successfully execute all tests by using the tests/runalltests.bat file
11. Execute liveness test (e.g., Sanity Test) on Google Colab
12. Execute GangSu workflows (e.g., Workflow1 and Workflow2) on Google Colab
13. Execute build.bat to check into PyPI ... be sure you updated the version number in build.bat first
14. Again, successfully execute all tests by using the tests/runalltests.bat file, Gang Su workflows and the Sanity Test. (Change Sanity Test to fetch py4cytoscape from PyPI instead of Github.)
15. Check any/all changes to the user manual and fix them now. (Note that the manual is automatically re-compiled when changes are made to the Master branch in Github.)
16. Create a new Github tag (in the Releases section on the far right of the Github GUI)
17. Start a branch to contain the next round of py4cytoscape changes.

Test Suites

py4cytoscape is supported by extensive test suites that benefit py4cytoscape users as follows:

• Verify that all API functionality operates as documented
• Verify that changes to py4cytoscape don't break working functionality

These test suites are not intended to verify Cytoscape or CyREST operation, though they may have that side effect. Their main purpose is to verify that py4cytoscape functions either properly call CyREST or pre/post-process CyREST data. So, they test that each function parameter has an intended affect in the context of one or more CyREST calls. The payoff is confidence in py4cytoscape functions over both the immediate and long term.

Single tests or groups of tests can be executed from the command line per the py4cytoscape Installation instructions.

Surprising (but true!) general rules of thumb:

• Creating a test for a py4cytoscape function may take between 2x and 5x the effort needed to create the function itself. Combined with the effort to document py4cytoscape functions, the overall time needed to create the function itself may be only 30% of the total effort.

• Unless code is tested, it can reasonably assumed to be buggy ... either in its definition or execution. Untested code is essentially buggy code.

• For a function or capability to be useful to a user, it must be documented in a place where a user can find it. In addition to testing functions, there must be appropriate function documentation (in the function's header and in the .rst files in the docs directory). Test cases are a rich source for documentation and examples.

Test Suite Construction

The py4cytoscape test suite is created under the rules of the Python unittest framework, and exists in the tests directory. Just as each py4cytoscape Python module contains a collection of py4cytoscape functions, there are corresponding test case files that contain tests for individual functions. For example, the networks module (networks.py) contains over 20 functions; the corresponding test case is tests_networks.py, and it contains individual tests that validate each networks function.

An individual test creates a testing environment and then verifies that each variant of a specific function produces an expected result (i.e., some change in the network, its properties, or the file system). For example, the test_networks.test_get_network_list test loads the galFiltered network and calls networks.get_network_list with various combinations of parameters.

At heart, an individual test:

• Captures the state (pre-state) before the function is executed
• Executes the function with a particular combination of parameters and may return a value
• Verifies that the value is what is expected
• Captures the state (post-state) after the function is executed
• Verifies that the post-state is different than the pre-state, and is the state that's expected

Note that these tests also verify that functions return expected results (e.g., exceptions) when incorrect parameters are passed.

Test Suite Usage

The test suite can be used in the following circumstances:

• During function development ... especially when Test Driven Development is practiced
• To verify that changes to a function don't break existing functionality
• To verify that new versions of Cytoscape don't cause functions to return incorrect results

To support this, any changes to a function must be followed up with new tests as appropriate. For example, changes in the networks.get_network_list function should be reflected by appropriate tests added/changed/removed in the test_networks.test_get_network_list function.

License

py4cytoscape is released under the MIT License (see LICENSE.rst file):

    Copyright (c) 2018-2020 The Cytoscape Consortium
    Barry Demchak <[e-mail]>