search

dib-lab / khmer

In-memory nucleotide sequence k-mer counting, filtering, graph traversal and more
http://khmer.readthedocs.io/
Other
756 stars 295 forks source link

Separate libkhmer (C++) from khmer (Python) #1030

Open blahah opened 9 years ago

blahah commented 9 years ago

I want to build tools on top of khmer. However, I don't necessarily want to write those tools in Python. There is a lot of valuable stuff in the C++ backend libkhmer, so I'm using that directly.

However, if I want to do the normal thing and git submodule khmer, I have to pull down over 100MB from the khmer repo every time I clone - that's a lot of extra stuff (and in modern development/testing environments people often clone a lot). If libkhmer were separated out it could be cleanly used as a library in any project (including khmer), without that 100MB overhead.

So, request: separate out libkhmer into its own repo, then submodule it into the main khmer repo.

ctb commented 9 years ago

ref http://ivory.idyll.org/blog/2015-modifying-our-dev-process.html,

I would like to defer any decision or action on this until (when and if) renewed funding is obtained. I have no objections to merging libkhmer easier to use but I don't think we can support a split into two projects.

+1 on reducing development/clone footprint; much of the stuff in data/ is now unnecessary, I think.

On Tue, May 26, 2015 at 08:22:46AM -0700, Richard Smith-Unna wrote:

I want to build tools on top on khmer. However, I don't necessarily want to write those tools in Python. There is a lot of valuable stuff in the C++ backend libkhmer, so I'm using that directly.

However, if I want to do the normal thing and git submodule khmer, I have to pull down over 100MB from the khmer repo every time I clone - that's a lot of extra stuff (and in modern development/testing environments people often clone a lot). If libkhmer were separated out it could be cleanly used as a library in any project (including khmer), without that 100MB overhead.

So, request: separate out libkhmer into its own repo, then submodule it into the main khmer repo.

Reply to this email directly or view it on GitHub:

https://github.com/dib-lab/khmer/issues/1030

C. Titus Brown, ctbrown@ucdavis.edu

mr-c commented 9 years ago

@kdmurray91 and I have talked about a partial step towards this: making liboxli (also known as khmer's lib/*.{cc,hh}) be just another library that the CPython code is linked against. It would give us more flexibility in modifying the build and avoid many of the setuptools weirdness that we have to work around (compiling C++ code with gcc instead of g++ for example).