Open Stack

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).

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


    Richard


On 19 November 2014 06:43, Richard Jones <r1chardj0n3s at gmail.com> wrote:

> On 19 November 2014 03:14, Radomir Dopieralski <openstack at sheep.art.pl>
> wrote:
>
>> On 18/11/14 12:54, Matthias Runge wrote:
>> > On Tue, Nov 18, 2014 at 09:36:00PM +1100, 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. 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 :)
>> >
>> > For me, it's more work to turn packages into bower, or to translate
>> > bower packages to system packages.
>> >
>> > But that is purely because we don't have bower packaged currently in
>> Fedora.
>> > I would vote for the cleaner way (whatever that is).
>> >
>> > XStatic is obviously not the cleanest way, but a good compromise in most
>> > situations.
>>
>> The way I thought about it, we would simply replace the Bower packages
>> with the corresponding system packages, by just changing the path in the
>> settings.py file.
>>
>> Maybe an example would help illustrate it.
>> Currently we have something like this:
>>
>> STATICFILES_DIRS = [
>>     ('horizon/lib/angular',
>>        xstatic.main.XStatic(xstatic.pkg.angular).base_dir),
>>     ('horizon/lib/angular',
>>        xstatic.main.XStatic(xstatic.pkg.angular_cookies).base_dir),
>>     ('horizon/lib/angular',
>>        xstatic.main.XStatic(xstatic.pkg.angular_mock).base_dir),
>>     ('horizon/lib/bootstrap_datepicker',
>>        xstatic.main.XStatic(xstatic.pkg.bootstrap_datepicker).base_dir),
>>     ('bootstrap',
>>        xstatic.main.XStatic(xstatic.pkg.bootstrap_scss).base_dir),
>> ...
>> ]
>>
>> We would replace that with:
>>
>> STATICFILES_DIRS = [
>>     ('horizon/lib/angular',
>>        os.path.join(BASE_DIR, 'bower_modules/angular'),
>> ...
>> ]
>>
>> or wherever bower puts the files. Now, the packagers would replace those
>> lines with:
>>
>> STATICFILES_DIRS = [
>>     ('horizon/lib/angular',
>>        '/usr/lib/javascript/angular'),
>> ...
>> ]
>>
>> or whatever the packages in their distribution use. It's less work than
>> having to make a whole xstatic package just to put that single path in
>> there. The horizon system package would already depend on all the
>> javascript library packages, so we are sure the files are there.
>>  <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
> +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.
>
> 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.
>
>
>      Richard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/84ecdfcd/attachment.html>