From Bioinformatics.Org Wiki
Graham has a created a python API that is in the process of being transitioned onto Git.
Currently, the move to python buys a lot of platform independence. In the bigger picture, using jython will reduce birch to only needing java as a dependency.
To solve a large number of problems, a "BIRCH Shell/Server daemon" should be written. This would allow for:
- A client (biolegato)/server structure for BIRCH
- Providing a consistent, system independent shell for BIRCH
- This will solve threading problems, and will allow for a single java instance to run all birch code using a jython virtual machine.
- In the future, this will also allow for remote biolegato instances, using socket communication between the daemon backend for the birch shell.
The BIRCH daemon would just be an infinite-loop turing machine, waiting for requests from a client, and responding to those requests.
- It will allow for scripts to be called as modules, and will be the backend that handles all calls from the BIRCH shell, and any biolegato clients.
- This will be the portion of BIRCH that is always running in the background.
The BIRCH shell will just be a frontend for the BIRCH daemon, providing text/command based I/O to the user, simulating a simplistic shell. The idea here is to use this to replace the system shell for text based interactions, providing a consistent UI.
It should work transparently, inheriting the users PATH variable, so that they can use it like any other shell.
This part will be very simple to code, and it will likely be very small in Jython.
Emerging python API
Common tasks in scripts:
- create temp directory and run program there
- if input contains multiple items, iterate the steps below
- sanity check of parameters, files
- convert file formats
- create input files
- resource controls
- run in background
- add annotation to output
- launch viewers or write files
- notify when complete
- remove temporary files and directories
We can use the existing getbirch code jython code for much of this, but both getbirch and the existing scripts must be refactored for this.
1. All Python scripts begin with #!/usr/bin/env python
2. Python scripts use either the .py or .pyc extension. This should also reflected in the documentation.
3. Override system default Python with a symbolic link in $BIRCH/local/bin-xxx-xxx.
All of the python scripts have been updated to work well with the "pydoc" built-in python module.
- Pydoc works by using the "doctest" module, to run through a script, which posed a problem for most of the scripts:
- This problem was solved by creating the "-pydoc" parameter, which when received turns off the scripts normal execution.
A master documentation generating script has also been created, "birchdoc.py". Running birchdoc.py should create an html_help directory with all of the documentation for the scripts (in the current working directory)
We need a centralized location for python documentation. I suggest the psgendb public_html directory, using a script to automatically run pydoc.
We need to make sure that all scripts can be run under Jython. That way we could potentially have a BIRCH that requires ONLY Java, and does not need to have Python installed on the system.
Dale already has a lot of Python classes that are known to be compatible.
We should move away from calling Python scripts by name. Instead, make calls to our API within the current Python VM.