On 11/17/2014 06:54 PM, Radomir Dopieralski wrote: > - A tool, probably a script, that would help packaging the Bower > packages into DEB/RPM packages. I suspect the Debian/Fedora packagers > already have a semi-automatic solution for that.
Nop. Bower isn't even packaged in Debian. Though I may try to do it (when I'm done with other Mirantis stuff like packaging Fuel for Debian...). On 11/18/2014 07:59 AM, Richard Jones wrote: > I was envisaging us creating a tool which generates xstatic packages > from bower packages. I'm not the first to think along these > lines http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html I think that's a very good idea! > I wrote the tool today, and you can find it here: > > https://github.com/r1chardj0n3s/flaming-shame AWESOME ! :) Then now, everyone is happy. Thank you. On 11/18/2014 04:22 PM, Radomir Dopieralski wrote: > If we use Bower, we don't need to use Xstatic. It would be pure > overhead. Bower already takes care of tracking releases and versions, > and of bundling the files. All we need is a simple line in the > settings.py telling Django where it puts all the files -- we don't > really need Xstatic just for that. The packagers can then take those > Bower packages and turn them into system packages, and just add/change > the paths in settings.py to where they put the files. All in one > place. The issue is that there's often not just a single path, but a full directory structure to address. That is easily managed with a Debian xstatic package, not sure how it would be with Bower. On 11/18/2014 06:36 PM, Richard Jones wrote: > I guess I got the message that turning bower packages into system > packages was something that the Linux packagers were not keen on. What I'm not a fan of, is that we'll have external dependencies being bumped all the time, with unexpected consequences. At least, with xstatic packages, we control what's going on (though I understand the overhead work problem). By the way, I went into bower.io as I wanted to have a look. How do I download a binary package for let's say jasmin? When searching, it just links to github... On 11/19/2014 12:14 AM, Radomir Dopieralski wrote: > We would replace that with: > > STATICFILES_DIRS = [ > ('horizon/lib/angular', > os.path.join(BASE_DIR, 'bower_modules/angular'), > ... > ] This would only work if upstream package directory structure is the same as the one in the distribution. For historical reason, that's unfortunately often not the case (sometimes because we want to keep backward compatibility in the distro because of reverse dependencies), and just changing the path wont make it work. On 11/19/2014 03:43 AM, Richard Jones wrote: > +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. s/lib/share/ However, I'm almost sure that wont be enough to make it work. For example, in Debian, we have /usr/share/javascript/angular.js, not just /usr/share/javascript/angular. So django-bower would be searching on the wrong path. On 11/19/2014 12:25 PM, Richard Jones wrote: > In their view, bower components don't need to be in global-requirements: > > - there are no other projects that use bower components, so we don't > need to ensure cross-project compatibility > - we can vet new versions of bower components as part of standard > Horizon change review Maybe that's right for the OpenStack project, but that is a problem at least for me, as I wont be constantly looking at Horizon dependencies, just at the global-requirements.txt. So I'm afraid I may miss some new stuff, and miss the deadline for the next release if I don't pay attention to it. :( Anyway, that's not so bad, I can try to adapt, but I just wanted to raise my concern so that everyone knows about it. Last thing: I'm currently a bit afraid of what will happen, as I don't know the tools (bower and such). I wish I had a bit more time to test them out, but I don't... :( So, I'm just raising my concerns even if 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. Cheers, Thomas _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
