track.splice

[mskilab]

where should we put this?

I like keeping it gTrack - I think it shows off gTrack very nicely, however it relies on read.bam, so we have a little dependency crisis

otherwise we should at least put into skitools

[KhagayN]

would it be a good idea to include it in gTrack? and since it relies on read.bam, wouldn't bamUtils be a good place for it?

[mskilab]

well it relies on both, so if we include in one package then we have to add a dependency to the other

actually gTrack supports bams and ucsc formats, so it will need to depend on bamUtils.

so let's keep in gTrack

On Wed, Mar 30, 2016 at 8:13 PM, Khagay Nagdimov notifications@github.com wrote:

would it be a good idea to include it in gTrack? and since it relies on read.bam, wouldn't bamUtils wouldn't be a good place for it?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/mskilab/gTrack/issues/7#issuecomment-203692251

[KhagayN]

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

[imielinski]

Let’s wait to see what Jeremiah thinks

On March 30, 2016 at 8:30:26 PM, Khagay Nagdimov (notifications@github.commailto:notifications@github.com) wrote:

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/mskilab/gTrack/issues/7#issuecomment-203695704

This electronic message is intended for the use of the named recipient only, and may contain information that is confidential, privileged or protected from disclosure under applicable law. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or use of the contents of this message including any of its attachments is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and destroy all copies of this message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.

[walaj]

What if we did it the other way around. gTrack is most exciting / closest to release, and I don't want to have to release bamUtils ahead of it just for one function. We can switch it into a later release of gTrack later (and thus the bamUtils dependency), since adding functions is not a problem for backwards compatibility.

On Mar 31, 2016, at 4:54 AM, Marcin Imielinski notifications@github.com wrote:

Let’s wait to see what Jeremiah thinks

On March 30, 2016 at 8:30:26 PM, Khagay Nagdimov (notifications@github.commailto:notifications@github.com) wrote:

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/mskilab/gTrack/issues/7#issuecomment-203695704

This electronic message is intended for the use of the named recipient only, and may contain information that is confidential, privileged or protected from disclosure under applicable law. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or use of the contents of this message including any of its attachments is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and destroy all copies of this message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email. — You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[mskilab]

Ok sounds fine in principle regarding waiting for later releases that depend on bamUtils

Kind of a letdown though if we can't show an example with plotting reads. This was one big use case e.g. plotting discordant pair clusters around rearrangements. Is there a way to implement that without read.bam or Rsamtools? Can our examples use external packages that our package does not depend on?

Eventually I'd like to work in direct bam compatibility - i.e. let bam path be a file input. Right now we have a user make their own granges and then wrap a gTrack around that object

On Thursday, March 31, 2016, Jeremiah Wala notifications@github.com wrote:

What if we did it the other way around. gTrack is most exciting / closest to release, and I don't want to have to release bamUtils ahead of it just for one function. We can switch it into a later release of gTrack later (and thus the bamUtils dependency), since adding functions is not a problem for backwards compatibility.

On Mar 31, 2016, at 4:54 AM, Marcin Imielinski <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Let’s wait to see what Jeremiah thinks

On March 30, 2016 at 8:30:26 PM, Khagay Nagdimov ( notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');<mailto: notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');>) wrote:

ah okay and then I'll add read.bam to bamUtils and add the dependency of bamUtils in gTrack?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub< https://github.com/mskilab/gTrack/issues/7#issuecomment-203695704>

This electronic message is intended for the use of the named recipient only, and may contain information that is confidential, privileged or protected from disclosure under applicable law. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or use of the contents of this message including any of its attachments is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and destroy all copies of this message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email. — You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/mskilab/gTrack/issues/7#issuecomment-203909362

[walaj]

Yeah, I see what you mean regarding the examples. Even if it's in "suggests", it won't make it onto CRAN without having all the dependent and suggested packages on their as well... May be that we just try and release bamUtils before gUtils, even we have the bandwidth to get this ready.

[mskilab]

ok sounds good ..

One interim option would be to use Rsamtools in the examples, i.e. using their native bam access with whatever is the bulky syntaxx

This would be uglier but would avoid having to get bamUtils ready. It would add an Rsamtools dependency to gTrack, but that dependency would be in our plan anyway (whether directly or indirectly)

Another option is add read.bam back to gUtils - which would add an Rsamtools dependency to gUtils. I could see reasons for not wanting to do that .. but maybe not the worst thing

On Thu, Mar 31, 2016 at 12:47 PM, Jeremiah Wala notifications@github.com wrote:

Yeah, I see what you mean regarding the examples. Even if it's in "suggests", it won't make it onto CRAN without having all the dependent and suggested packages on their as well... May be that we just try and release bamUtils before gUtils, even we have the bandwidth to get this ready.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/mskilab/gTrack/issues/7#issuecomment-204016469

[KhagayN]

just to summarize - should we keep read.bam in BamUtils and release that package. Then, include BamUtils as a dependency in gTrack before gTrack release.

[mskilab]

yes I think so

On Mon, Dec 5, 2016 at 3:00 PM, Khagay Nagdimov notifications@github.com wrote:

just to summarize - keep read.bam in BamUtils and release that package. Then, include BamUtils as a dependency in gTrack before gTrack release.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mskilab/gTrack/issues/7#issuecomment-264960378, or mute the thread https://github.com/notifications/unsubscribe-auth/AL-0kSPmfwdV-dr40aAUD2NZm9Bv2xRAks5rFG1dgaJpZM4H8Rrp .