You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Same over here.
Here's a quick workaround (for now) for noobies and for one of those days when you just cannot think:
(replace miniconda3 by what you use -- conda or whatever, and my_env with the name of your environment)
cd ~/miniconda3/envs/my_env/bin/
ln -s ../opt/transdecoder/TransDecoder transdecoder
rm TransDecoder.LongOrfs # for cleanup
rm TransDecoder.Predict # for cleanup
exec bash && conda activate my_env # to reload the terminal
# Now you can run it with "transdecoder".
Apparently, there is a single binary now that automatically runs the LongOrfs and the Predict functions by default in that order, as far as I have understood (source).
I honestly do not know, but I think the main binary changed in newer versions to be easier to use.
However, I found the separated binaries (TransDecoder.LongOrfs and TransDecoder.Predict) in this path: ~/miniconda3/envs/my_env/opt/transdecoder/util/
I do not know the detail, whether these work the same as the main binary, or they are old and now legacy binaries. I guess that is something the developer is to answer.
hey all,
The latest version was meant to be easier to run as a one-step execution.
You can still run it piecemeal if you want or just run the earlier
multi-step version for now.
best,
Brian
Ok, just to be sure on the recommended way to run transdecoder. Does it make sense (under any circumstance) to run each step separately? If so, then it would be nice to also have TransDecoder.LongOrfs and TransDecoder.Predict in $PATH. Or, on the contrary, is this behavior deprecated (or not recomended)?
before, you had to run it separately because there's an intermediate
optional step of doing blast or pfam searches to consider homology. This is
now baked in to the main runner now to facilitate that process.
The entire pipeline is the same as before, just reorganized to provide a
simpler single interface to it.
Thanks for the clarifications, but the binaries are still missing.
@evatosco solutions works since the binaries seem to be under opt/transdecoder but, if these binaries are the ones intended for use, shouldn't they be added to $PATH by the conda recipe?
Thanks for the clarifications, but the binaries are still missing.
@evatosco solutions works since the binaries seem to be under opt/transdecoder but, if these binaries are the ones intended for use, shouldn't they be added to $PATH by the conda recipe?
Hi,
I imagine that the idea was to use the updated and merged transdecoder binary at /opt/transdecoder/TransDecoder , that is probably why there is no mention of the separate packages anymore.
Having no working binaries in the conda env is kind of a problem. I need my conda env to be reproducible and workable for others testing my workflows. Can this problem be updated and / or fixed semi-quickly? Whether or not its TransDecoder or TransDecoder.LongestOrf whatever I don't care, if I install the conda env, I just need it to work on activation and not require a workaround. Ya know? Or has this been fixed and I don't know about it?
Activity
evatosco commentedon Jun 12, 2026
Hi there, thanks for the report!
Same over here.
Here's a quick workaround (for now) for noobies and for one of those days when you just cannot think:
(replace miniconda3 by what you use -- conda or whatever, and my_env with the name of your environment)
Apparently, there is a single binary now that automatically runs the LongOrfs and the Predict functions by default in that order, as far as I have understood (source).
Hope it helps!
fgvieira commentedon Jun 12, 2026
Does that mean that it is no longer possible to run each command separately?
evatosco commentedon Jun 12, 2026
I honestly do not know, but I think the main binary changed in newer versions to be easier to use.
However, I found the separated binaries (
TransDecoder.LongOrfsandTransDecoder.Predict) in this path:~/miniconda3/envs/my_env/opt/transdecoder/util/I do not know the detail, whether these work the same as the main binary, or they are old and now legacy binaries. I guess that is something the developer is to answer.
Hope it helps!
brianjohnhaas commentedon Jun 12, 2026
fgvieira commentedon Jun 12, 2026
Ok, just to be sure on the recommended way to run
transdecoder. Does it make sense (under any circumstance) to run each step separately? If so, then it would be nice to also haveTransDecoder.LongOrfsandTransDecoder.Predictin$PATH. Or, on the contrary, is this behavior deprecated (or not recomended)?brianjohnhaas commentedon Jun 12, 2026
fgvieira commentedon Jun 16, 2026
Thanks for the clarifications, but the binaries are still missing.
@evatosco solutions works since the binaries seem to be under
opt/transdecoderbut, if these binaries are the ones intended for use, shouldn't they be added to$PATHby the conda recipe?evatosco commentedon Jun 17, 2026
Hi,
I imagine that the idea was to use the updated and merged transdecoder binary at /opt/transdecoder/TransDecoder , that is probably why there is no mention of the separate packages anymore.
fgvieira commentedon Jun 17, 2026
But that binary is not in
$PATHand, therefore, not accessible when the conda environment is loaded.mike2vandy commentedon Sep 20, 2026
Having no working binaries in the conda env is kind of a problem. I need my conda env to be reproducible and workable for others testing my workflows. Can this problem be updated and / or fixed semi-quickly? Whether or not its TransDecoder or TransDecoder.LongestOrf whatever I don't care, if I install the conda env, I just need it to work on activation and not require a workaround. Ya know? Or has this been fixed and I don't know about it?
Ask for build 1 or later of TransDecoder 6.0.0