[openstack-dev] [Horizon] the future of angularjs development in Horizon
zigo at debian.org
Thu Nov 20 17:05:44 UTC 2014
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
I think that's a very good idea!
> I wrote the tool today, and you can find it here:
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
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 = [
> 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
However, I'm almost sure that wont be enough to make it work. For
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.
More information about the OpenStack-dev