Would it make sense to implement serde traits?

I think the contig module and Contig struct have a naming issue. From my understanding, "contig" is a well-established term from genome assembly that describes a contiguously assembled sequence. This is, e.g., supported by the contig header in VCF... Also, I believe genome::AbstractInterval::contig shares the description.

What about renaming this as "linear"?

When xclip or yclip is suffix, pretty print gives wrong sequence, the problem lies in src/alignment.rs file where you should skip x_i and y_i bases before actual clip sequence, I think, like below

The conventional-prs.yml Actions workflow, which uses amannn/action-semantic-pull-request, does not accept deps (which we want for release-please) as a commit type as shown by the CI failure from #58:

Unknown release type "deps" found in pull request title "deps: bump serde from 1.0.136 to 1.0.156". 

Available types:
 - feat: A new feature
 - fix: A bug fix
 - docs: Documentation only changes
 - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
 - refactor: A code change that neither fixes a bug nor adds a feature
 - perf: A code change that improves performance
 - test: Adding missing tests or correcting existing tests
 - build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
 - ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 - chore: Other changes that don't modify src or test files
 - revert: Reverts a previous commit

The available types are configurable though (https://github.com/amannn/action-semantic-pull-request#configuration) and I will open a PR to add deps.

Currently, alignment::Alignment::pretty() arbitrarily produces output with 100 characters per line:

I think it's better to allow the user to have control over it.

If 'y' overhangs at the beginning of the alignment, the sequence of 'x' is shown. There is a pull request which should fix this and contains a test illustrating the problem.

The types from this trait could be useful in more places if they were to implement the Display and Debug traits.

rust-bio and rust-htslib both use thiserror to automagically create custom error types, but this crate uses quickerror. Shoud we let it be so, or homogeneize it with the other ones?

What is the reason for the choice of string formatting for contigs to be

The display format for a Contig is chr:start-end(+/-/.). The boundaries are given as a half-open 0-based interval, like the Rust Range and BED format.

I would thing that the convention is that if the coordinate is written as 'chr:start-end' then it is 1-based-end-inclusive, while 'chr start end' would be 0-based-end-exclusive. AT least this is the convention that is followed by UCSC and plethora of utilities.

Hi,

I think this crate is a very good idea.

But now AbstractInterval is clearly built for only genome concerned, so it could be more generic.

First replace contig by sequence, isn't very important but it is not very important but all the intervals do not concern only the contigs.
I would also like to replace the str type by a generic type that implement Index for a Range which would allow the user to use the data structure he wants.

I propose something like this :

pub type Position = usize;

pub trait AbstractInterval<I: Index<Range<Position>>> {

    /// Identifier for a genomic contig, e.g., a chromosome
    fn sequence(&self) -> &I;
    
    /// Interval on the contig
    fn range(&self) -> Range<Position>;

    fn subsequence(&self) -> &<I as Index<Range<Position>>>::Output; 
}
    
    
pub struct Interval<I: Index<Range<Position>>> {
    sequence: I,
    range: Range<Position>,
}

impl AbstractInterval<String> for Interval<String> {

    fn sequence(&self) -> &String {
        &self.sequence
    }

    fn range(&self) -> Range<Position> {
        self.range.clone()
    }
    
    fn subsequence(&self) -> &str {
        return &self.sequence[..][self.range.clone()];
    }
}

Thank

This is specified in VCF4.x for allowing representation of arbitrary genomic structural variants.

A while ago, I put together a set of data types to represent genomic annotations or regions -- I had a few key features, which included the need to keep track of strand information some of the time, and the ability to track a "spliced" genomic location (in the sense of pre-mRNA splicing).

Briefly, it features a few different location types -- single positions, contiguous locations, and spliced locations -- as well as a general location trait. They're generic over the type of the chromosome name (so you could use String, an interned Rc, or an i32 target ID from a BAM file) and over the strandedness (some annotations may be stranded while others aren't, and this provides a type-level guarantee to separate this). They also feature some useful interval math, e.g., given a position and an annotation, find the offset of the position in the annotated feature.

I was revisiting some of this recently and made a quick attempt to add this as a module in rust-bio-types. Here is this annot module. Would something of this general design be interesting, in this crate, or in the rust-bio crate?