<div dir="ltr">On 17 November 2014 21:54, Radomir Dopieralski <<a href="mailto:openstack@sheep.art.pl">openstack@sheep.art.pl</a>> wrote:<br>><br>> On 17/11/14 09:53, Martin Geisler wrote:<br>><br>> [...]<br>><br>> > As Richard said, npm and bower are not competitors. You use npm to<br>> > install bower, and you use bower to download Angular, jQuery, Bootstrap<br>> > and other static files. These are the static files that you will want to<br>> > include when you finally deploy the web app to your server.<br>> ><br>> > Before using Bower, people would simply download Angular from the<br>> > projects homepage and check it into version control. Bower is not doing<br>> > much, but using it avoids this bad practice.<br>> ><br>> > There is often a kind of "compilation step" between bower downloading a<br>> > dependency and the deployment on the webserver: minification and<br>> > compression of the JavaScript and CSS. Concatenating and minifying the<br>> > files serve to reduce the number of HTTP requests -- which can make an<br>> > app much faster.<br>> ><br>> > Finally, you use Grunt/Gulp to execute other tools during development.<br>> > These tools could be a local web server, it could be running the unit<br>> > tests. Grunt is only a convenience tool here -- think of it as a kind of<br>> > Makefile that tells you how to lunch various tasks.<br>><br>> Thank you for your explanations.<br>><br>> The way I see it, we would need:<br>> - Grunt both in the development environment and packaged (to run tests,<br>> etc.),<div><br>I'm increasingly coming to think that we can avoid grunt.<br><br>- serve is handled by django runserver<br>- test running is handled by tox<br>- livereload could be handled by <a href="https://pypi.python.org/pypi/livereload">https://pypi.python.org/pypi/livereload</a> (it'd be really nice if someone could get support for this rolled in to django-livereload...)<br>- 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</div><div><br></div><div>So, the tools we need packaged for Linux are:</div><div><br></div><div>- karma</div><div>- jasmine (already in Fedora, I believe)</div><div>- selenium (I believe this is already done in Fedora and Debian)</div><div>- phantomjs (definitely already done!)<br><br> <br>> - Bower in the development environment,<br>> - Bower configuration file in two copies, one for global-requirements,<br>> and one for the Horizon's local requirements. Plus a gate job that makes<br>> sure no new library or version gets included in the Horizon's before<br>> getting into the global-requirements,<div><br></div><div>Could you perhaps elaborate on this? How do you see the workflow working here?</div><div><br></div><div>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 <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html">http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html</a></div><div><br></div><div>I will be looking into creating such a tool today.</div><div><br></div><div><br>> - A tool, probably a script, that would help packaging the Bower<br>> packages into DEB/RPM packages. I suspect the Debian/Fedora packagers<br>> already have a semi-automatic solution for that.</div><div><br></div><div>Yep, that is indeed their problem that they'd have already solved for the existing xstatic packages.</div><div><br></div><div><br>> - A script that would generate a file with all the paths to those<br>> packaged libraries, that would get included in Horizon's settings.py<br></div><div><br></div><div>If we stick with xstatic, we don't need this :)</div><div><br></div><div><br></div><div>     Richard</div><div><br></div></div></div>