On 03/10/2016 11:48 AM, Beth Elwell wrote: > >> On 10 Mar 2016, at 07:46, Richard Jones <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> It has been mentioned, xstatic packages can block the gate. We >> currently >> control xstatic package releases, thus we can roll back, if something >> goes wrong. >> >> If we're pulling directly with npm/bower, someone from the outside can >> break us. We already have the situation with pypi packages. >> With proper packages, we could even use the gate to release those >> packages and thus verify, we're not breaking anyone. >> >> >> We're going to have potential breakage (gate breakage, in the >> integrated tests) any time we release a package (regardless of release >> mechanism) and have to update two separate repositories resulting in >> out-of-sync version specification and expectation (ie. >> upper-constraints specification and Horizon's code expectation) as >> described in my OP. The only solution that we're aware of is to >> synchronise updating those two things, through one of the mechanisms >> proposed so far (or possibly through a mechanism not yet proposed.) > > If we will anyway have potential breakage I don’t understand why the > better solution here would not be to just use the bower and npm tools
We control the breakages, and we're trying to find a solution (if you didn't notice, many where proposed in this thread). > which are standardised for JavaScript They are a *very bad* standard which doesn't work at all with downstream distributions. Unless someone adds a system wide registry for javascript (the say way that if you apt-get a Python package, pip wont download it), then we can't use it. > and would move Horizon more > towards using widely recognised tooling Recognized by who? Certainly not downstream distributions. This is a nightmare. > from within not just Openstack > but the wider development community. What community are you talking about? That JavaScript community which breaks APIs every 2 weeks? Please re-read this: https://github.com/openstack/horizon/blob/master/doc/source/topics/packaging.rst and especially the part: "Why we use XStatic" We have every few months some Horizon contributors advocating for pushing toward this direction, however, none have yet shown a way to solve what Xstatic does. Until this is done, please refrain from writing: "hey, everyone uses X, so let's do the same" without valid technical argumentation. Yes, using npm / bower / gulp / you-name-it, may make your Horizon contributor life easier. But that's *not* the only thing to consider. > Back versions always need to be > supported for a time, however I would add that long term this could end > up saving time and create a stable longer term solution. Long term, I would like to see more contributions to the upstream JavaScript tooling to make it behave reasonably. Until this is done, we can't use it. Cheers, Thomas Goirand (zigo) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
