prashantsengar
removing strict 'Flask' ver. num. from req. file.
this commit solves #78
the 'Flask' package in requirements.txt is strictly specified to be 1.1.2 whereas its dependencies(jinja2 in this case) are downloaded to latest versions. This leads to a common bugs like #78 which is solved in this sf answer
Updating 'requirements.txt' to remove version numbering, so that the latest package is always downloaded, fixes the issue.
It is not a good approach to remove dependency pinning for an application. If there is a breaking change in Flask, then it would mean that ArrangePy will not run as well. https://stackoverflow.com/a/28510546/9809865
You can pin it to the latest version (after testing, however) or make it loose (>=x.y.z <=a.b.c).
Would you be willing to take this up?
Sure. Currently the latest version of flask(2.1.2) builds the app successfully.
I have loosely pinned the flask version to >=2.0.0 as the exact flask version requiring update in its jinja2 dependency(and many others) is this 2.0.0 one.. The web code works as usual in the app without any scaffolding required for moving from 1.x.x to 2.x.x
Thank you for updating it, @azzamzafar! It still does not address the problem if there is a new version of Flask (say 3.0.0) which adds a breaking change. Any user installing ArrangePy at that time will not be able to run it because of that. The pinning should have an upper limit for that case. Can it be changed to like - >=2.0.0, <=2.2.0 (whatever the latest version is)
Yeah, sorry, it was embarrassingly silly of me to overlook that. i was preoccupied with dependency resolution. since its trivial single word change, please edit the merge itself if you wish to.
Sure. Currently the latest version of flask(2.1.2) builds the app successfully.
I have loosely pinned the flask version to >=2.0.0 as the exact flask version requiring update in its jinja2 dependency(and many others) is this 2.0.0 one.. The web code works as usual in the app without any scaffolding required for moving from 1.x.x to 2.x.x