<div class="gmail_quote">On Fri Nov 21 2014 at 4:06:51 AM Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/17/2014 06:54 PM, Radomir Dopieralski wrote:<br>
> - A tool, probably a script, that would help packaging the Bower<br>
> packages into DEB/RPM packages. I suspect the Debian/Fedora packagers<br>
> already have a semi-automatic solution for that.<br>
<br>
Nop. Bower isn't even packaged in Debian. Though I may try to do it<br>
(when I'm done with other Mirantis stuff like packaging Fuel for Debian...).<br></blockquote><div><br></div><div>Just to be clear, it's not bower itself (the command-line tool) that needs packaging, just the components that bower itself packages.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/18/2014 07:59 AM, Richard Jones wrote:<br>
> I was envisaging us creating a tool which generates xstatic packages<br>
> from bower packages. I'm not the first to think along these<br>
> lines<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>March/031042.html</a><br>
<br>
I think that's a very good idea!<br>
<br>
> I wrote the tool today, and you can find it here:<br>
><br>
> <a href="https://github.com/r1chardj0n3s/flaming-shame" target="_blank">https://github.com/<u></u>r1chardj0n3s/flaming-shame</a><br>
<br>
AWESOME ! :)<br>
Then now, everyone is happy. Thank you.<br></blockquote><div><br></div><div>Well, no, but at least it exists ;)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/18/2014 04:22 PM, Radomir Dopieralski wrote:<br>
> 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<br>
> place.<br>
<br>
The issue is that there's often not just a single path, but a full<br>
directory structure to address. That is easily managed with a Debian<br>
xstatic package, not sure how it would be with Bower.<br></blockquote><div><br></div><div>I'm not sure what the difference is (unless it's just related to the Debian-specific historical issue you raise below). xstatic and bower are remarkably similar a directory to be packaged and some meta-data describing it.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/18/2014 06:36 PM, Richard Jones wrote:<br>
> I guess I got the message that turning bower packages into system<br>
> packages was something that the Linux packagers were not keen on.<br>
<br>
What I'm not a fan of, is that we'll have external dependencies being<br>
bumped all the time, with unexpected consequences. At least, with<br>
xstatic packages, we control what's going on (though I understand the<br>
overhead work problem).<br></blockquote><div><br></div><div>The dependencies won't be bumped any faster than reviewers allow, though I realise that's not necessarily going to make you sleep any easier. Hmm.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">By the way, I went into <a href="http://bower.io" target="_blank">bower.io</a> as I wanted to have a look. How do I<br>
download a binary package for let's say jasmin? When searching, it just links to github...<br></blockquote><div><br></div><div>Again; bower is not npm! Jasmine is a command-line program which is packaged by npm. Bower packages bundles of stuff that are included in web applications. bower itself, a command-line tool, is packaged by npm, but itself manages other packages which are not command-line things, but just bundles of css, javascript, images, fonts, etc. that are resources for web applications to use.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/19/2014 12:14 AM, Radomir Dopieralski wrote:<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>
This would only work if upstream package directory structure is the same<br>
as the one in the distribution. For historical reason, that's<br>
unfortunately often not the case (sometimes because we want to keep<br>
backward compatibility in the distro because of reverse dependencies),<br>
and just changing the path wont make it work.<br>
<br>
On 11/19/2014 03:43 AM, Richard Jones wrote:<br>
> +1 to all that, except I'd recommend using django-bower to handle the<br>
> static collection stuff. It's not documented but django-bower has a<br>
> setting BOWER_COMPONENTS_ROOT which would make the above transition much<br>
> simpler. You leave it alone for local dev, and packagers setup<br>
> BOWER_COMPONENTS_ROOT to '/usr/lib/javascript/' or wherever.<br>
<br>
s/lib/share/<br>
<br>
However, I'm almost sure that wont be enough to make it work. For<br>
example, in Debian, we have /usr/share/javascript/angular.<u></u>js, not just<br>
/usr/share/javascript/angular. So django-bower would be searching on the<br>
wrong path.<br></blockquote><div><br></div><div>That is unfortunate. It may be that Debian therefore has to special-case angular to handle that case.</div><div><br></div><div>I think the general idea of following the component pattern set by bower (separate directories with no risk of conflicts, and using the bower.json meta-data to allow automatic configuration of the component) is too good to dismiss though. Far less work for everyone, including packagers.</div><div><br></div><div>Perhaps the new packages should have "bower" in their name?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/19/2014 12:25 PM, Richard Jones wrote:<br>
> In their view, bower components don't need to be in global-requirements:<br>
><br>
> - there are no other projects that use bower components, so we don't<br>
> need to ensure cross-project compatibility<br>
> - we can vet new versions of bower components as part of standard<br>
> Horizon change review<br>
<br>
Maybe that's right for the OpenStack project, but that is a problem at<br>
least for me, as I wont be constantly looking at Horizon dependencies,<br>
just at the global-requirements.txt. So I'm afraid I may miss some new<br>
stuff, and miss the deadline for the next release if I don't pay<br>
attention to it. :(<br>
Anyway, that's not so bad, I can try to adapt, but I just wanted to<br>
raise my concern so that everyone knows about it.<br></blockquote><div><br></div><div>Yep. There is the bower.json file which we'll have in Horizon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Last thing: I'm currently a bit afraid of what will happen, as I don't<br>
know the tools (bower and such). I wish I had a bit more time to test<br>
them out, but I don't... :( So, I'm just raising my concerns even if<br>
sometimes they may have no root, in the hope that we all find the best solution that fits everyone. I hope the way I did in this thread is ok.<br></blockquote><div><br></div><div>Yep!</div><div><br></div><div><br></div><div>     Richard </div></div>