我正在尝试使用apache2托管django应用程序。但是出现以下错误。
RuntimeError at / cannot cache function '__shear_dense': no locator available for file '/home/username/project/env/lib/python3.6/site-packages/librosa/util/utils.py'
在运行Django服务器时，不会遇到此类错误，但是在apache2服务器的情况下会引发此错误。
该问题是wsgi错误，似乎是由于librosa和numba的导入引起的。这些天我一直被困住。任何有关如何解决此问题的指示都将受到高度赞赏。
答案 0 :(得分：2)
花了几天的时间对付这个问题，并阅读了所有我能用谷歌搜索的内容后，我才知道了。来了。
TL; DR：：请确保将NUMBA_CACHE_DIR环境变量设置为您的应用程序可以写入的内容，并确保该变量实际上已传播到您的应用程序，并且应用程序看到它。在某些环境中，这在本地测试中可能会出现，但在部署时可能会无提示地丢失。 真的，请进行测试！我大概读了十遍这个建议，我以为我检查了所有内容，但问题出在其他地方，但最后我错了。
详细信息。
罪魁祸首是缓存目录的位置，以及numba软件包中对这些目录的相应写入权限的缺乏，而numba软件包是librosa的依赖项。 Librosa尝试使用numba装饰器来缓存某些功能。 Numba有四个定位器类，用于通知将缓存写入何处。
我认为Numba会尝试变得更聪明，并使用回退策略，具体取决于用户指定的内容（例如专用的缓存目录）以及系统中可用于写入缓存的内容。结果，它通常可以工作，但是当它不起作用时，您似乎指定了一个完美的缓存位置，它会被后备策略丢失或覆盖，然后失败。
我注意到，其中一些后备缓存定位策略包括尝试缓存在库的根目录（在本例中为librosa的）内，并缓存到/root/something...，但是我现在很确定NUMBA_CACHE_DIR正确，就可以了。
以下是我的具体情况：在AWS Lambda中使用librosa。帮助我的是在numba/core/caching.py
我的用例：AWS Lambda
如果了解到这一点，则可能是您使用的限制性环境具有一些不寻常的默认值。
在我的案例中是AWS Lambda，该应用程序的Docker容器的根是只读安装的。因此，缓存到库根目录的策略之一不是一种选择。
缓存目录本身没有默认为/ tmp。最终，我在CloudFormation模板中通过NUMBA_CACHE_DIR: /tmp对其进行了显式设置，并在本地调用时成功进行了测试，但是当我通过ZIP文件将其手动部署到AWS进行测试时，我忘记了再次在控制台中对其进行设置以“无”进入应用程序，但失败了。
一旦我在lambda控制台中指定了缓存目录env var，它就会起作用。
有用的各种来源