Update SeqAn to version 2.0?

[hendrikweisser]

OpenMS is currently using SeqAn version 1.4.1, which is the version before the current 2.0.

One potentially relevant change from 1.4.1 to 2.0 is an update to the amino acid alphabet, which added the letter "J" (ambiguity code for "I or L", seqan/seqan#762). This would be useful to have e.g. in ConsensusID, which uses SeqAn for computing sequence alignments between peptides (which may occasionally contain "J"s).

[ealbiter]

Actually, OpenMS can't be compiled against SeqAn 2.0. I am try to build the package in Arch Linux and the current version in AUR is 2.0. The compilation fails because some header files can't be found (for example guess_stream_format.h). A quote from SeqAn release note:
"Many modules are backward compatible with the 1.4.2 release. However, we had to change the API of some modules, like the I/O modules.
If you want to switch to the new release (https://github.com/seqan/seqan/releases/tag/seqan-v2.0.0), you will likely have to adapt your application. "

[hroest]

it seems like a good idea for a future release but requires some work. Is the availability of the J letter very important to anybody? I dont think that many FASTA files of fully sequenced organisms still contain many J instances or did anybody ever have a problem with those?

[sagitter]

Hello.

Does OpenMS currently support Seqan-2.3-* ?

[jpfeuffer]

Hi.
Unfortunately not, since seqan2.x requires compilation with C++11 and we did not upgrade yet because of our python bindings.

[jpfeuffer]

Maybe we will upgrade in the next release, depending on how the discussion at our developer meeting turn out and how many TODOs arise from the changes in seqan's IO module.

[hroest]

I guess this relates to #980

[hroest]

well there are two questions here: 1) what is the version of seqan that comes officially with OpenMS and 2) whether we support seqan 2.3

I think we could try and compile with seqan 2.3 and see whether there are major changes preventing compilation. If not, then we could just support it but officially ship a previous version so that both constraints can be fulfilled. Does that sound feasible?

given the comment above from @saxonbeta we would have to include some preprocessor directives to make it work? But we will have to do that work anyways at some point in the future, so ...

[jpfeuffer]

Yes, we will have a SeqAn developer with us in the developer meeting @cpockrandt. We will see if we can do some preinvestigation and try to finish the upgrade (or the support of the upgraded version as you correctly said) during the meeting.
Nonetheless, we should also think about a solution (e.g. transition plan) for the python bindings since less preprocessor directives would be favorable and we have to build, test and support yet another combination.

[hroest]

probably it would be good to draft a commit and see how large the changes would be. I am also against preprocessor stuff since they are a pain to test. But in the end the question is very simple and has been over at the C++11 thread for quite a while

• do we need/want to support Python 2.7 on Windows any more
• do we need/want to support older RHEL clusters

these are political questions, not a technical ones. Giving up 2.7 on Windows may compromise the idea of user-friendlyness somewhat even though I dont know what the state of Python on Windows is. At least on Linux, migration has just started

[cbielow]

following up on DevRetreat: after OpenMS 2.2 we will switch to C++11, which will allow us to use Seqan 2.x.
Since there is currently an 'annoyance' involving the FASTA file reader in Seqan 2.x we will wait until that is fixed (seqan/seqan#2054) -- or as a last resort, go back to reading FASTA using our code again

[sagitter]

Seqan upstream has just announced the release of Seqan3 at the end of this month.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.