Closed ciaradunks closed 3 years ago
+1 We can define this in the requirements
.
It would be good to know what makes it problematic for the future, because it means we cannot expect enjoying new releases of pyomo with this tool and as pyomo is at its core it would be problematic for long term survival. Maybe it is also worth checking if the problem is not in oemof directly, then we could write an issue on oemof's repo. @c-moeller are you aware of pyomo problems with your previous oemof code?
I agree that the short term fix is to freeze the dependency (with a comment in the requirements.txt file)
@SabineHaas I can not find it anymore, but I think @Piranias had the same issue once and you wrote a larger issue on it? Or was it a comment in a PR? Can you find it and link it here, I think it included the reason as to why this is happening.
yes, I had this problem when updating pvcompare
to MVS v0.5.5
and decided to require Pyomo 5.7.2
This is the original comment
https://github.com/greco-project/pvcompare/pull/251#issuecomment-797552976
I don't know why this is happening, but what takes very long is creating the oemof model, see https://github.com/greco-project/pvcompare/issues/251#issuecomment-796815766_
If the latest version of pyomo is used, running the tests is very slow and the benchmark tests are not executed.
Pyomo == 5.7.3 (problematic) Pyomo == 5.7.2 (fine) Pyomo == 5.7.0 (fine)
I couldn't see this mentioned in the documentation but it could be useful to include it.