-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: add version constraints #203
Conversation
Note to the reviewer of this PR:
I recommend doing all this in a GitHub codespace so that there's zero chance of you messing up your local installation of TRTools. Github codespaces are pre-configured development containers running editors on the cloud, and are basically free for academic use. To create a codespace on this branch, click on "Create codespace" on this page. Wait a bit for the codespace to get set up and then open a terminal ( Ctrl + ` ) and run After you're done, you can manually edit the pyproject.toml file to ensure each version of each dependency still has a |
unless anyone has any objections, I'll probably merge this PR by EOD Melissa and I agreed (via personal conversation) that these version constraints are probably low enough for now. We can of course revisit them if someone requests us to |
this pr also pins numpy to a version less than 2.0 for now, until we have a chance to test it and make sure it doesn't break anything |
I've opened this PR for us to develop minimum version constraints for our dependencies. I've made a first pass at this, which I hope to refine with the help of whoever reviews this! These constraints will reduce the chance that users encounter bugs when installing TRTools in environments that have old versions of our dependencies.
my strategy
I started with the versions of each dependency that had just been published at the time of the first commit to the repository (see 2b1f871). As expected, the tests did not pass when run with some of those versions. In general, support for old dependencies can be broken by ongoing code maintenance and new features.
So I incrementally bumped certain versions until the tests passed (see 4be0437). Some combination of binary search through our dependencies' versions and ctrl+f through our dependencies' changelogs was helpful here. It was also super helpful to use poetry, a popular dependency management tool, to help me navigate version incompatibilities. Based on my experience, I think we will need to continue using it if we want to keep supporting specific python versions. (Refer to #202 for more details.)
a bug requiring us to drop support for py 3.6
For example, there was one instance when I discovered that some of the tests (for code that was added to TRTools recently) would only pass for versions of pandas >= 1.2.0. I suspect that there must be some sort of bug in TRTools when used in combination with versions of pandas < 1.2.0. But when I tried to constrain pandas to >= 1.2.0, poetry informed me that I would be breaking support for python 3.6. Apparently, pandas dropped support for python 3.6 in 1.2.0.
So I had to drop TRTools' support for python 3.6, too. In any case, I don't think the version of setuptools that comes with python 3.6 supports pyproject.toml files (source), so we would probably have to revert our pyproject.toml file to a setup.py file if we wanted to continue supporting python 3.6. Also, we will have to drop support for python 3.6 (and certain versions of numpy, cyvcf2, and pysam) anyway when we merge the
haptools.data
andtr_harmonizer
libraries, sincehaptools.data
only supports python 3.7+.