Figure what we should or want to do regarding the plink functionality

[gregorgorjanc]

See

https://pypi.org/project/alphaplinkpython/

https://bitbucket.org/hickeyjohnteam/alphaplinkpython

[gregorgorjanc]

There is a Python package for PLINK BED files https://pypi.org/project/bed-reader/ - should we just use that and build a converter? This is Python only code I think, so might be less efficient than what David wrote for alphaplinkpython, but by using “established” Python solution we get OS portability and speed ups and fixes from upstream when they occur.

FYI Python/Rust extension for PLINK at https://towardsdatascience.com/nine-rules-for-writing-python-extensions-in-rust-d35ea3a4ec29, but that should be for the Python package!

[XingerTang]

There is a Python package for PLINK BED files https://pypi.org/project/bed-reader/ - should we just use that and build a converter? This is Python only code I think, so might be less efficient than what David wrote for alphaplinkpython, but by using “established” Python solution we get OS portability and speed ups and fixes from upstream when they occur.

FYI Python/Rust extension for PLINK at https://towardsdatascience.com/nine-rules-for-writing-python-extensions-in-rust-d35ea3a4ec29, but that should be for the Python package!

@gregorgorjanc I read about the package, and I think the advantages of using it might be:

• The package is written partly Python and partly Rust, so it is quite efficient, nevertheless, I don't need to install the Rust compiler to use it.
• The documentation and the code are written in a clear and informative way.
• alphaplinkpython is written in C++ so I guess it cannot be fixed in the short term.

The disadvantages are:

• It seems that it requires Python version >= 3.7 (it doesn't explicitly specify this, but the software is only tested for version 3.7 or above)
• It also requires other Python packages (pandas>=0.25.1, pooch>=1.4.0, chardet>=5.1.0) that the Alphatools don't require. The current dependency on numba is already causing problems while using Alphatools in Rstudio, as Alphatools requires numba, and numba requires llvmlite, the llvmlite is the one not that compatible with Rstudio, although it can be fixed.
• It has an open issue Bed() and Pheno() etc don't like Windows Paths, but the issue is actually not for this package (bed-read) but another package that requires this package (pysnptools). I'm wondering why the issue is opened here. But, after all the tests for the package are run on all three operating systems, and all passed. There shouldn't be any issues related to the platform.

Overall, I think it should be a good option for the Alphatools.

[gregorgorjanc]

@XingerTang thanks for exploring these pros and cons!!!

I am leaning to using the bed-reader, BUT I guess we would still need some sort of a converter to our format!?

[XingerTang]

@gregorgorjanc Yes, we need a converter, but as data are stored in numpy arrays for both, I guesss it won't be too complicated.

[CarlKCarlK]

I saw your reference to bed-reader@ . Thank for you for considering its use!

Inspired by @XingerTang's comments, I've updated the project so that it only (by default) depends on numpy. The dependency on pooch is now optional (needed only if you want to download my sample files). The dependencies on pandas and chatdet are gone. There is new optional dependency on scipy, but it is only needed if you want to create scipy sparse matrices.

The new version is on PyPi in beta. You can install it with:

pip install bed-reader==1.0.0b3

The beta documentation is here: https://fastlmm.github.io/bed-reader/beta/.

If you have any questions or suggestions, just let me know.

-- Carl
p.s. With respect to versions, we try to support all officially supported versions of Python, which is currently 3.8 to 3.12. We support Linux/Mac (including ARM)/Windows.

[gregorgorjanc]

Maybe we look into sgkit https://github.com/pystatgen/sgkit