<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 November 2014 19:22, Radomir Dopieralski <span dir="ltr"><<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 18/11/14 00:59, Richard Jones wrote:<br>
> On 17 November 2014 21:54, Radomir Dopieralski <<a href="mailto:openstack@sheep.art.pl">openstack@sheep.art.pl</a><br>
</span><span class="">> <mailto:<a href="mailto:openstack@sheep.art.pl">openstack@sheep.art.pl</a>>> wrote:<br>
>> - Bower in the development environment,<br>
>> - Bower configuration file in two copies, one for global-requirements,<br>
>> and one for the Horizon's local requirements. Plus a gate job that makes<br>
>> sure no new library or version gets included in the Horizon's before<br>
>> getting into the global-requirements,<br>
><br>
> Could you perhaps elaborate on this? How do you see the workflow working<br>
> here?<br>
<br>
</span>Basically we would have an additional file in the global-requirements<br>
directory, for listing the JavaScript dependencies. Then we would have a<br>
check on the Horizon's gate that would check Horizon's Bower<br>
configuration against that global-requirements file.<br>
<br>
This way we keep the same process for JavaScript libraries as we have<br>
for Python libraries: first you submit a patch to the<br>
global-requirements and have the dependency accepted by the infra team<br>
and packagers (checked against licenses, version conflicts, etc.), and<br>
then you add it to Horizon's dependencies. Of course you can submit both<br>
patches at once, just the Horizon one will fail the gate until the<br>
global-requirements one gets merged.<br>
<span class=""><br>
> Given that Horizon already integrates with xstatic, it would be messy<br>
> (and potentially confusing) to include something so it *also* integrated<br>
> with bower. I was envisaging us creating a tool which generates xstatic<br>
> packages from bower packages. I'm not the first to think along these<br>
> lines <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html</a><br>
<br>
</span>If we use Bower, we don't need to use Xstatic. It would be pure<br>
overhead. Bower already takes care of tracking releases and versions,<br>
and of bundling the files. All we need is a simple line in the<br>
settings.py telling Django where it puts all the files -- we don't<br>
really need Xstatic just for that. The packagers can then take those<br>
Bower packages and turn them into system packages, and just add/change<br>
the paths in settings.py to where they put the files. All in one place.<br></blockquote><div><br></div><div>I guess I got the message that turning bower packages into system packages was something that the Linux packagers were not keen on. Did I get the message wrong there? If so, *and* we can get the bower stuff through #infra and global-requirements then yes, we should totally try to avoid adding the xstatic layer :)</div><div><br></div><div><br></div><div>    Richard</div></div><br></div></div>