Source distribution/Linux packaging

[yann.ponty]

Dear Xiang Jun,

With a Master student (Pauline Pommeret - Ecole Normale Supérieure/Ecole Polytechnique), we are currently enriching the 3D RNA-specific capabilities of BioPython, to allow users to load PDB files and compute such things as dihedral angle computation, base-pairs annotations...

On this last feature, we would like to include wrappers for DSSR, as your software is clearly gaining popularity within the growing field of RNA structural biology. For this, there are mainly two options:
a) We assume that the software is available/installed, and that some 'standard' path is set (related functions fail with some human readable error message if the executable is not found);
b) DSSR is installed "on demand" if unavailable, ideally using some package manager (for Linux/Mac OS).

Option a. is the quick-and-dirty option, but typical users will tend to stick to whatever tools they are used to (probably RNAView, still very popular despite its increasing obsolescence).

Option b. means that the source code of DSSR must be packaged and regularly updated, but it will make it much easier for users to "give it a shot" and move away from alternatives. Note that most package repositories do not require the license to be "open" (eg Debian non-free packages https://www.debian.org/distrib/packages), and you may retain any IP privileges on the code.

The main constraint on your part with the second option is distributing a source code version of DSSR. From your website, it is not clear if you would oppose such an option (my apologies if I missed something here).

Is a source code distribution (+Linux/MacOS packaging) an option for DSSR?

Best,

Yann

[xiangjun]

Hi Yann,

It is so nice to hear from you, and I appreciate your kind words on DSSR. I am well aware of the two options you mentioned. The binary distribution is the current choice for the following reasons:

• DSSR is still under active development. The last thing I want to see is potentially many variants that are lagging behind the main steam yet still claim to be 'DSSR'. As a concrete example, the current DSSR-Jmol integration is based on DSSR v1.1.1-2014apr11 from the Jmol side! The interface is based on the DSSR web server I host at Columbia University. I add extra checking in latter DSSR releases to make the integration works. Yet this is still a better choice than a 'customized' DSSR variant, which is bound to be quickly out of date.
• DSSR is designed with simplicity in mind. The program is self-contained, without any run-time dependency. Get DSSR up and running should not take more than a few minutes, even for a regular user. So accessibility to DSSR should not be a concern.
• A paper on DSSR is coming soon. When the paper is 'officially' out, I will add a new section on the 3DNA Forum so interested users can reproduce all the reported table and figures. Reproducing DSSR results should not be a problem.
• I am actively supporting DSSR. As you can see by browsing the Forum, all posted questions are always promptly addressed. Users should have no concerns on using DSSR and getting support.

In the long run, I may make DSSR open source, as I did for the SCHNAaP/SCHNArP and 3DNA programs. For DSSR, it is just not that time yet. At this stage, what I am focusing on is the quality and functionality of the software per se; I do not want to get distracted by other issues.

Option a. is the quick-and-dirty option, but typical users will tend to stick to whatever tools they are used to (probably RNAView, still very popular despite its increasing obsolescence).

DSSR can be taken as a safe replacement of RNAView, whose algorithms for base-pair identification is actually based on an early version of the 3DNA find_pair and analyze program. For verification, try the following in the top-level RNAVIEW directory:

RNAVIEW [579] grep -R Xiang-Jun *
BASEPARS/Atomic_A.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
BASEPARS/Atomic_C.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
BASEPARS/Atomic_G.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
BASEPARS/Atomic_I.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
BASEPARS/Atomic_P.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
BASEPARS/Atomic_T.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
BASEPARS/Atomic_U.pdb:REMARK    By Xiang-Jun Lu <xiangjun@rutchem.rutgers.edu>, 2000
Binary file bin/rnaview matches
src/analyze.c:    fprintf(fp, "Curves base-pair parameters (by Xiang-Jun Lu)\n");
src/analyze.c:    fprintf(fp, "FreeHelix base-pair parameters (by Xiang-Jun Lu)\n");
grep: test/.#t: No such file or directory
RNAVIEW [580] grep -R 3dna *
src/fpair_sub.c:/* read in H-bond length upper limit etc from <misc_3dna.par> */
grep: test/.#t: No such file or directory

Users will switch from RNAView to DSSR when they realize the benefits. As outlined above, there are virtually no technical barriers for the transition. Nevertheless, the conversion from RNAView to DSSR would take time, but I believe it is just a timing issue.

For integrating DSSR to BioPython, I am willing to adapt the software to streamline the process. As an example, the DSSR-Jmol integration benefits from the undocumented --jmol option. I can do something similar, and quick, as long as you let me know the specific requirements of the interface.

Best regards,

Xiang-Jun

[xiangjun]

Hi Yann,

As a follow up of our previous communication, I'd like to draw your attention to the new DSSR --json option. As of v1.3.5-2015sep09, the DSSR JSON export can be taken as stable. I am currently working with Bob Hanson to simplify and extend the Jmol/DSSR integration via JSON.

Best regards,

Xiang-Jun