<div dir="ltr">I've just had a long discussion with #infra folk about the global-requirements thing, which deviated (quite naturally) into a discussion about packaging (and their thoughts were in line with where Radomir and I are heading).<div><br></div><div>In their view, bower components don't need to be in global-requirements:</div><div><br></div><div>- there are no other projects that use bower components, so we don't need to ensure cross-project compatibility</div><div>- we can vet new versions of bower components as part of standard Horizon change review<br><div><br></div><div><br></div><div> Richard</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 November 2014 06:43, Richard Jones <span dir="ltr"><<a href="mailto:r1chardj0n3s@gmail.com" target="_blank">r1chardj0n3s@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On 19 November 2014 03:14, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 18/11/14 12:54, Matthias Runge wrote:<br>
> On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote:<br>
>> I guess I got the message that turning bower packages into system packages<br>
>> was something that the Linux packagers were not keen on. Did I get the<br>
>> message wrong there? If so, *and* we can get the bower stuff through #infra<br>
>> and global-requirements then yes, we should totally try to avoid adding the<br>
>> xstatic layer :)<br>
><br>
> For me, it's more work to turn packages into bower, or to translate<br>
> bower packages to system packages.<br>
><br>
> But that is purely because we don't have bower packaged currently in Fedora.<br>
> I would vote for the cleaner way (whatever that is).<br>
><br>
> XStatic is obviously not the cleanest way, but a good compromise in most<br>
> situations.<br>
<br>
</span>The way I thought about it, we would simply replace the Bower packages<br>
with the corresponding system packages, by just changing the path in the<br>
settings.py file.<br>
<br>
Maybe an example would help illustrate it.<br>
Currently we have something like this:<br>
<br>
STATICFILES_DIRS = [<br>
('horizon/lib/angular',<br>
xstatic.main.XStatic(xstatic.pkg.angular).base_dir),<br>
('horizon/lib/angular',<br>
xstatic.main.XStatic(xstatic.pkg.angular_cookies).base_dir),<br>
('horizon/lib/angular',<br>
xstatic.main.XStatic(xstatic.pkg.angular_mock).base_dir),<br>
('horizon/lib/bootstrap_datepicker',<br>
xstatic.main.XStatic(xstatic.pkg.bootstrap_datepicker).base_dir),<br>
('bootstrap',<br>
xstatic.main.XStatic(xstatic.pkg.bootstrap_scss).base_dir),<br>
...<br>
]<br>
<br>
We would replace that with:<br>
<br>
STATICFILES_DIRS = [<br>
('horizon/lib/angular',<br>
os.path.join(BASE_DIR, 'bower_modules/angular'),<br>
...<br>
]<br>
<br>
or wherever bower puts the files. Now, the packagers would replace those<br>
lines with:<br>
<br>
STATICFILES_DIRS = [<br>
('horizon/lib/angular',<br>
'/usr/lib/javascript/angular'),<br>
...<br>
]<br>
<br>
or whatever the packages in their distribution use. It's less work than<br>
having to make a whole xstatic package just to put that single path in<br>
there. The horizon system package would already depend on all the<br>
javascript library packages, so we are sure the files are there.<br>
<div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"></a></div></div></blockquote><div><br></div></div></div><div>+1 to all that, except I'd recommend using django-bower to handle the static collection stuff. It's not documented but django-bower has a setting BOWER_COMPONENTS_ROOT which would make the above transition much simpler. You leave it alone for local dev, and packagers setup BOWER_COMPONENTS_ROOT to '/usr/lib/javascript/' or wherever.</div><div><br></div><div>bower also has a concept of entry points - there a "main" value in the bower.json which identifies the Javascript, CSS, font and other files to include in the index.html to have the library loaded into your application. Saves a bunch of manual editing to get things right when you include the library. Sadly, the current django-bower plugin doesn't use any of that, though it does handle the collectstatic stuff.</div></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra"> Richard</div><div class="gmail_extra"><br></div></font></span></div>
</blockquote></div><br></div>