Re: [Transdecoder-users] Announcement: Transdecoder release r20140704
Extracting likely coding regions from transcript sequences
Brought to you by:
bhaas
From: Brian H. <bh...@br...> - 2015-01-09 14:44:55
|
Hi all, In general, I prefer for the system to be retained as a fully self-contained unit. I really would *not* want any of the scripts to show up in /usr/bin, or for the perl libraries to contaminate (for lack of a better word) any site-perl libraries. Keeping everything self-contained within the one package allows one to easily move it around or delete it in its entirety. In this case, they simply need to have Transdecoder in their PATH, and ideally the whole thing just works. The one key issue that I'm happy to consider is what dependencies to bundle with the system vs. what dependencies require users to supply externally. In this case, my personal opinion is that the very commonly installed bioinformatics tools and very large software packages (ie. samtools, hmmer, bowtie, etc.) need not be bundled, but for other ones that may be less commonly installed and dependent within the software package (ie. ffindex, parafly, and possibly cdhit) or those that have specific version compatibility issues (ie. rsem in Trinity), I'm inclined to simply bundle them into the package to ease installation and better ensure overall system integrity. As long as those bundled packages remain inside the self-contained software package, and don't contaminate or replace other already-installed software tools, and are specifically leveraged by the driving software within the self-contained package (by internally adjusting PATH env var, or looking for tools via relative paths to the package installation directory), I think it should be both acceptable and non-disruptive. I should also mention that we don't and won't plan to bundle any software that has restrictive licensing issues nor that is not open source. Now - with that said - TransDecoder does need to be seriously overhauled with respect to its makefile, build mechanism, etc., and separately from that, it needs some additional enhancements to make it even more useful to users in the next release. So, after this next generation of the Trinity software goes out, we'll tackle TransDecoder and whip it into shape. But note that, unless there's some major shift in my method of operation with respect to software packaging issues, it'll fit the general description that I outline above. Alexie and I will work on it together, and we'll try to do what we can to address any lingering issues that Martin might raise. cheers, ~brian |