Open Stack

On Fri Nov 21 2014 at 4:06:51 AM Thomas Goirand <zigo at debian.org> wrote:

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

Just to be clear, it's not bower itself (the command-line tool) that needs
packaging, just the components that bower itself packages.



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

Well, no, but at least it exists ;)



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

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.



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

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.



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

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.



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

That is unfortunate. It may be that Debian therefore has to special-case
angular to handle that case.

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.

Perhaps the new packages should have "bower" in their name?



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

Yep. There is the bower.json file which we'll have in Horizon



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

Yep!


     Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141121/e6786aea/attachment-0001.html>