Re: [Transdecoder-users] Announcement: Transdecoder release r20140704

[Brian H. <bh...@br...>]

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