FRED-2 / OptiType

Precision HLA typing from next-generation sequencing data
BSD 3-Clause "New" or "Revised" License
188 stars 75 forks source link

Python 3 support #33

Closed holtgrewe closed 8 years ago

holtgrewe commented 8 years ago

Would you consider a patch adding Python 3 support to OptiType? This would greatly simplify our lives at the place I work as this would make OptiType integrate better with the rest of our stack.

b-schubert commented 8 years ago

You can finde the 2to3 modified files in the following branch:

https://github.com/FRED-2/OptiType/tree/feature/2to3

Could you please tell me if that already suffices?

holtgrewe commented 8 years ago

Hi @b-schubert I think 2to3 makes an upgrade from Python v2 to v3 but does not allow both versions. I created PR #34 using future and six which gives support for both versions. Also, I found a problem in the case that pysam does not work properly (as is the case with Bioconda on my system).

By the way, what about (1) adding a tag/release here on Github and (2) making OptiType installable with a setup.py?

b-schubert commented 8 years ago

Great we'll have a look at it.

To your other questions:

(1) Definitely agree and will be done. (2) We discussed this previous and believe that it should not be possible to "install" OptiType via pip/setup.py since:

We instead provide a Dockerfile/image as of now which takes care of the installation.

andras86 commented 8 years ago

The original release is now tagged v1.0 and the current state v1.1.

holtgrewe commented 8 years ago

Hm, but pip is the way to install Python applications as well, e.g., Snakemake, etc.

I'll rebase my changes on top of yours

b-schubert commented 8 years ago

This might be the case for pure python applications or easily configurable projects that provide all contribs. But OptiType is unfortunately neither of those to applications. Even your PR #9 wouldn't work because table would fail due to the lack of HDF-5 libs.

And in my opinion, a pip-able application which still requires that all dependencies are prior installed and in the correct order, does not add any benefit and makes it much more problematic for people to figure out what went wrong during installation.

holtgrewe commented 8 years ago

OK, agreed. However, a setup.py nicely describes the requirements of a program and allows for a clone-and python setup.py installation into a $prefix/bin directory. This is the more similar to the usual way of installing software, e.g., using make install instead of copying the software to some directory and then stripping the test directory.

b-schubert commented 8 years ago

resolved in PR #36