Open Stack

On 17 November 2014 21:54, Radomir Dopieralski <openstack at sheep.art.pl>
wrote:
>
> On 17/11/14 09:53, Martin Geisler wrote:
>
> [...]
>
> > As Richard said, npm and bower are not competitors. You use npm to
> > install bower, and you use bower to download Angular, jQuery, Bootstrap
> > and other static files. These are the static files that you will want to
> > include when you finally deploy the web app to your server.
> >
> > Before using Bower, people would simply download Angular from the
> > projects homepage and check it into version control. Bower is not doing
> > much, but using it avoids this bad practice.
> >
> > There is often a kind of "compilation step" between bower downloading a
> > dependency and the deployment on the webserver: minification and
> > compression of the JavaScript and CSS. Concatenating and minifying the
> > files serve to reduce the number of HTTP requests -- which can make an
> > app much faster.
> >
> > Finally, you use Grunt/Gulp to execute other tools during development.
> > These tools could be a local web server, it could be running the unit
> > tests. Grunt is only a convenience tool here -- think of it as a kind of
> > Makefile that tells you how to lunch various tasks.
>
> Thank you for your explanations.
>
> The way I see it, we would need:
> - Grunt both in the development environment and packaged (to run tests,
> etc.),

I'm increasingly coming to think that we can avoid grunt.

- serve is handled by django runserver
- test running is handled by tox
- livereload could be handled by https://pypi.python.org/pypi/livereload
(it'd be really nice if someone could get support for this rolled in to
django-livereload...)
- watch is not handled by anything and it would be a shame to miss out on
automatic linting/testing, but I think we can live without it

So, the tools we need packaged for Linux are:

- karma
- jasmine (already in Fedora, I believe)
- selenium (I believe this is already done in Fedora and Debian)
- phantomjs (definitely already done!)


> - Bower in the development environment,
> - Bower configuration file in two copies, one for global-requirements,
> and one for the Horizon's local requirements. Plus a gate job that makes
> sure no new library or version gets included in the Horizon's before
> getting into the global-requirements,

Could you perhaps elaborate on this? How do you see the workflow working
here?

Given that Horizon already integrates with xstatic, it would be messy (and
potentially confusing) to include something so it *also* integrated with
bower. 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 will be looking into creating such a tool today.


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

Yep, that is indeed their problem that they'd have already solved for the
existing xstatic packages.


> - A script that would generate a file with all the paths to those
> packaged libraries, that would get included in Horizon's settings.py

If we stick with xstatic, we don't need this :)


     Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/27b1fbd3/attachment.html>