Many projects focus on adding features, often neglecting measures to maintain software quality. One reason for this is financing, may it because new features can sell new licenses or because project funding is connected with them. On the long run, of course, easy-to-maintain code also facilitates adding new features.
Currently, we are rewriting stuff “under the hood” of solph to prepare for future additions, including time-series aggregation. Also, experimental features are removed if they do not mature. (This includes the approach for cellular energy systems, we recommend to use named tuples as labels instead.) Every now and then we try to change our code to eliminate deprecation warnings in time. The release of NumPy 2.0 shows that maintaining compatibility is not always easy. Although it is actually an evolutionary milestone, Pyomo first seemed to be hit between the eyes. In particular, it does not check compatibility of installed dependencies. Never version state to be compatible to numpy<2.0 only, but at least sometimes incompatible versions are installed by pip.
Thus, software relying on Pyomo – such as solph – currently looks broken when latest versions of NumPy are installed. The only option is to downgrade NumPy and wait for Pyomo to update. Not only because this is not the first time Pyomo effectively breaks solph without a warning, we are considering other back-ends. Alternatives also promise faster processing. But this is a big maintenance job, and hard to fund using the current funding scheme of research projects.
