Infrastructure updates notice from Astropy Project

[pllim]

Hello from Astropy Project!

The following updates to your package might be necessary to ensure compatibility with the latest stable version of Astropy:

• [ ] MPLBACKEND is now set to Agg in ci-helpers, packages expecting interactive plotting should override it in .travis.yml
• [ ] Astropy 3.1 is not compatible with Numpy <1.13 versions. If you want to keep testing these older Numpy versions, please use ASTROPY_VERSION=3.0 or ASTROPY_VERSION=LTS in your Travis CI matrix.
• [ ] Add sphinx-astropy as a package dependency if you are using astropy-helpers 3.1 or later. Otherwise, your documentation build (e.g., on ReadTheDocs) might fail.
• [ ] If you are using six that is bundled with Astropy, please consider using the standalone six package instead.

If these are no longer applicable to you, please close the issue.

This is an automated issue for packages that opted in for automated astropy-helpers update. If this is opened in error, please let @pllim know.

xref astropy/astropy-procedures#108

[dhomeier]

I would add to that the last Astropy LTS to support Python 2 has been 2.0.16 in October 2019, and we expect affiliated packages to support Python 3 by now. I found that the GitHub HEAD can in fact be installed using pip on Python 3.9.9 without problems, and still passes all tests except 3 that are all related to a units error in omnifit.spectrum.BaseSpectrum.interpolate: https://github.com/RiceMunk/omnifit/blob/883f44b4a729711154fa5557d04ceac882995cd2/omnifit/spectrum/spectrum.py#L325 Since current versions of numpy already handle u.Quantity, the unit ist now preserved by np.interp and multiplying it in again creates a self.y.unit**2. Apart from this little bug, it would be great to have a Python 3.7-3.9 version of Omnifit on PyPI to have it easily installable (Python3.10 currently fails due to the use of use2to3 in setup.py).

[RiceMunk]

Hi!

I'm painfully aware of how out of date Omnifit is. It's on my list of things I'm trying to get to updating on my free time, but not terribly high on said list.

I'll see if I can this sorted out at some semi-reasonable span of time. In the meantime if there are any potential contributors out there who want to set up a PR on this, I'll be happy to review and merge it.

[dhomeier]

Thanks for the quick reply; I have taken the liberty of suggesting the bug fixes directly in #43, which I noticed already provides pretty complete Python 3 support (including 3.10!) Tests were passing locally, but I am afraid I cannot help much with getting a working CI configuration; the Astropy package templates or its own azure-pipelines.yml et al. might be of some help...

[RiceMunk]

Alright, so Omnifit v0.3.0 is now a thing. It at least supports python 3, and should be overall a bit less broken in modern environments.

I'll take a look through the documentation at some point, and make sure it's updating appropriately, and maybe set up some pipelines for that too if/when it's not.

Other than that, I'm going to probably just let Omnifit sit again for a while as I work on other stuff. If you folks at Astropy have any requirements or such for this, please let me know and I'll get around to it at some point.

[dhomeier]

Thanks and congratulations to getting everything to run and test smoothly! I just did a pip install omnifit under python 3.9. We have updated the status in the Affiliated Packages section accordingly.

So this should probably be safely operational for some time; I'll just note that we are going to ask for some brief citation guidelines (i.e. add a CITATION file) from affiliated packages in the future: https://github.com/astropy/astropy.github.com/pull/460/files Absolutely no urgency to act on this, but if you find some time again, it will only help increasing the visibility of the package and getting due credit for it.