Separating pygor from IGoR repo.

[penuts7644]

Hi Quentin,

I created this separated issue (based on pull request #26) to continue our talk in pygor development.

Since I'm working a lot with IGoR and pygor at the moment (check out the following git repo: https://github.com/penuts7644/TcrDataComparison), I would like be more involved with the development of pygor and its codebase. Many of the code pieces I'm writing in the git repo above could be additions to pygor, especially when my thesis work progresses.

To make pygor and IGoR easier to maintain, I propose the following:

• Separate pygor into another GitHub repository, from there pygor can be maintained and developed on its own, separately from IGoR.
• New versions of pygor can be committed to PyPI without having to make a new release of IGoR. This also applies the other way around where a new IGoR release doesn't have to release a new version of pygor, even when nothing has changed to pygor's code. This streamlines pygor's installation process (in my case for server use).
• Have the possibility to expand pygor's codebase without IGoR
• Let pygor have its own documentation including documentation webpage.

I would love to spend more of my time on the development process of pygor and I have no problem to take some initiative to set all of this up. Please let me know what you think :smile:

Cheers, Wout

[qmarcou]

Hi Wout!

Sorry for the long delay before my reply. Thank you very much for taking the lead on this one! As I previously stated I think it remains important that pygor is supplied along with IGoR and I think it should still be included as a git submodule.

Here are the pros and cons I see about this separation:

Pros:

• use of PyPi
• smooth integration of the AIRR format (http://docs.airr-community.org/en/latest/packages/airr-python/overview.html)

Cons:

• some pieces of pygor extract information from IGoR's fileformats. This creates an interdependency between IGoR's and pygor releases. This is why I think including pygor in IGoR's releases would be good.

Development directions:

• cython interface between IGoR and pygor (this would probably solve the first con). This would also be very helpful to prototype codes before implementing in C++
• a small library to make summary plot from IGoR's outputs/distributions etc
• implement selection, clone frequency distributions generation etc (this would also be a good reason for having a cython interface, as a lot of these would not necessarily require coding in C for performance)

Tell me if you have other ideas I will append them to the list!

[penuts7644]

Hi Quentin,

Sounds good! I have been taking some initiative on this one, since I needed to get started on doing some more of the master related work. Because of this I have cloned a version of pygor as one of my own repos (I made sure the your commit messages where carried over as well). You can find this version here: https://github.com/penuts7644/pygor and is installable via PyPI as well. I'm currently working on some refactoring work for the module (aka using more classes and separating the tools a bit more).

I agree with your pros and cons and am willing to implement these as time progresses. Just not right now because of my own priorities. Also I think that the cons can be solved (for now) by mentioning which version of pygor works with which version of IGoR in the readme file of pygor (or even IGoR).

Cython is really nice to implement for some speed improvements and I will also add some snippets for pythons own multiprocessing module (for example for pandas data frame manipulation tasks).

Have a great day!

Cheers, Wout