New installations of librosa break with numba 0.50.0

Describe the bug

Numba has had a new release (0.50.0) which breaks new installations of librosa. Importing librosa now returns:

  File "/site-packages/librosa/util/decorators.py", line 9, in <module>
    from numba.decorators import jit as optional_jit
ModuleNotFoundError: No module named 'numba.decorators'

To Reproduce

python -m venv venv
source venv/bin/activate
pip install librosa
python -c "import librosa"

Edit:

This was the warning message before the update:

/site-packages/librosa/util/decorators.py:9: NumbaDeprecationWarning:
An import was requested from a module that has moved location.
Import requested from: 'numba.decorators', please update to use 'numba.core.decorators'
or pin to Numba version 0.48.0. This alias will not be present in Numba version 0.50.0.

[JulianFerry]

Hi, sorry about the duplicate! I missed the closed issues. Isn’t it a bit strange to force the user to install the correct requirements themselves? Can’t this just be set in the requirements for the package?

If all dependencies strictly adhered to semantic versioning, then yes, that would work. The problem here is that numba introduced an API-breaking change with a relatively short deprecation cycle (less than 2 months!), and they don’t generally adhere to semantic versioning (neither do we), so it would be impossible to anticipate this kind of thing by pinning to version numbers. They have significantly more developer time and resources than we do, and we were not able to put out a release before the change took effect.

So I suppose my request/suggestion is to release a 0.7.3 with this bugfix soon

Thanks for the suggestion. At this point, we’re pretty close to the 0.8.0 release, and will just go for that rather than roll back changes to put out a point release for this issue.

Okay makes sense. I massively appreciate the detail you put in your responses by the way.

[bmcfee]

Hi, sorry about the duplicate! I missed the closed issues. Isn’t it a bit strange to force the user to install the correct requirements themselves? Can’t this just be set in the requirements for the package?

If all dependencies strictly adhered to semantic versioning, then yes, that would work. The problem here is that numba introduced an API-breaking change with a relatively short deprecation cycle (less than 2 months!), and they don’t generally adhere to semantic versioning (neither do we), so it would be impossible to anticipate this kind of thing by pinning to version numbers. They have significantly more developer time and resources than we do, and we were not able to put out a release before the change took effect.

So I suppose my request/suggestion is to release a 0.7.3 with this bugfix soon

Thanks for the suggestion. At this point, we’re pretty close to the 0.8.0 release, and will just go for that rather than roll back changes to put out a point release for this issue.