On 03/08/2016 05:52 AM, Richard Jones wrote: > In the Python world, we code around this by making Horizon compatible > with both the X and X1 versions of xstatic-angular (if it was a Python > library). In Javascript land this is much more difficult - Javascript > libraries tend to break compatibility in far more interesting ways. > Maintaining compatibility across CSS and font releases is also a > difficult problem, though changes here are unlikely to break Horizon > enough that gate tests would fail. So, solution 1 to the problem is: > > SOLUTION 1: always maintain Horizon compatibility across xstatic library > releases. > > This is potentially very difficult to guarantee. So, a second solution > has been proposed: > > SOLUTION 2: move the upper-constraints information for *the xstatic > libraries only* from the global upper-constraints file into Horizon's > repository. > > This allows us to atomically update both Horizon and the xstatic library > version, removing the potential to break because of the version > mismatch. Unfortunately it means that we have version compatibility > issues with anything else that wants to install alongside Horizon that > also uses xstatic packages. For example, Horizon plugins. We could move > Horizon plugins into the Horizon repository to solve this. /ducks > > A variation on this solution is: > > SOLUTION 3: allow Horizon to locally override upper-constraints for the > time needed to merge a patch in devstack. > > This solution allows Horizon to atomically update itself and the xstatic > library, but it also means installing Horizon in a CI/CD environment > becomes more difficult due to the need to always pull down the > upper-constraints file and edit it. We could code this in to tox, but > that doesn't help eg. devstack which needs to also do this thing. > > SOLUTION 4: vendor the javascript > > Heh. > > SOLUTION 5: have dependencies on xstatic move from global requirements > to Horizon > > This is similar to 2 & 3 with some of the same drawbacks (multiple users > of xstatic) but also we'd need a change to global-requirements handling > to ignore some entries in Horizon's requirements. > > Your thoughts on any and all of the above are requested.
SOLUTION 6: educate upstream and make them stop breaking the world. SOLUTION 7: Stop having dependencies on libraries that constantly break the world. SOLUTION 8: Stop using JavaScript. SOLUTION 9: Rewrite Horizon as QT client! :) Cheers, Thomas Goirand (zigo) P.S: While all of this is just for fun, I seriously believe that upstream JavaScript people should be educated to not break things every 2 weeks... though I don't think it will happen anytime soon. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
