Skip to content
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

Deprecation and versioning notes #97

Closed
AlecThomson opened this issue Oct 22, 2023 · 1 comment
Closed

Deprecation and versioning notes #97

AlecThomson opened this issue Oct 22, 2023 · 1 comment

Comments

@AlecThomson
Copy link
Contributor

There are some regions of RM-Tools which now deprecated, it would be nice to explicitly mark all code which is deprecated and make plans to remove it at some point. The deprecation package offers a very nice way to handle with via decorators. I've got a PR incoming that makes the obviously deprecated code as such.

I think we should also consider deprecating the large and unwieldy code that really should be handled by external packages. Namely: emcee, nestle, corner, and mpfit. The first three can probably be immediately replaced with their properly maintained versions. mpfit should probably be replaced by scipy tools (like curve_fit) but this might take some refactoring.

Finally, we need to catch up on some Python updates. Version 3.7 has reached end-of-life, we should consider sunsetting support. Further, we should add up to version 3.12 for testing. Further, Numpy version 2.0 is on the horizon with major, potentially breaking, changes. We should restrict our reqs to numpy < 2 until we decide to migrate.

I've wrapped up most of these suggestions into a PR, with the exception of removing the larger copies of external packages.

@Cameron-Van-Eck
Copy link
Collaborator

Merged. I also fixed the issues with the tests that appeared (not as a result of the changes in the code, but as a result of testing with other version of Python). There were two problems:

  • higher versions of numpy have removed the compatibility of np.percentile() with complex numbers (which affected some plotting code for QU fitting). Fixed this by splitting the real/imaginary components (which were already plotted separately).
  • higher versions of Python caused very minor (<1 part in 10^7) differences in outputs, which was causing some badly designed tests to fail (because it was doing string comparison instead of float comparison on the polynomial fit coefficients). I've cleaned up the broken test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants