<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 March 2016 at 18:23, Matthias Runge <span dir="ltr"><<a href="mailto:mrunge@redhat.com" target="_blank">mrunge@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4.alt.2:<br>
move to proper packages for static file management. I mean, they need to<br>
be built anyways.<br></blockquote><div><br></div><div>Please define what you mean by "proper packages" here. I *think* you might mean system packages (aka Debian or Red Hat) which is not feasible given other environments that Horizon runs under. Please correct me if I'm wrong!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It has been mentioned, xstatic packages can block the gate. We currently<br>
control xstatic package releases, thus we can roll back, if something<br>
goes wrong.<br>
<br>
If we're pulling directly with npm/bower, someone from the outside can<br>
break us. We already have the situation with pypi packages.<br>
With proper packages, we could even use the gate to release those<br>
packages and thus verify, we're not breaking anyone.<br></blockquote><div><br></div><div>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.)</div><div><br></div><div><br></div><div>I think that David's proposal is the only really feasible approach at this time:</div><div><br></div><div>1. Horizon maintains its own constrained version list for the xstatic packages,</div><div>2. Plugins to Horizon must depend on Horizon to supply xstatic packages except where they use additional packages that Horizon does not use, and</div><div>3. We avoid installing app-catalog (the system, not the plugin) in the integrated tests (I don't believe doing this is even on the ... "horizon" so to speak) *or* in a Debian / Red Hat (i.e. system-packaged) system that also has Horizon installed. Or we try to convince app-catalog to stay lock-step with Horizon's xstatic versions. I understand the risk of a collision between app-catalog and Horizon in the same system-packaged environment is very low.</div><div><br></div><div><br></div><div>     Richard</div><div><br></div></div></div></div>