I think the only outstanding question is how developers and non-packagers populate the bower_components directory - that is, how is bower expected to be available for them?<br><div><br></div><div>I think following the Storyboard approach is a good idea: isolate a known-working node/bower environment local to horizon which is managed by tox - so to invoke bower you run "tox -e bower <command>". No worries about system installation or compatibility, and works in the gate.</div><div><br></div><div>Horizon installation (whenever a pip install would be invoked) would then also have a "tox -e bower install" invocation.</div><div><br></div><div>Storyboard[1] uses a thing called nodeenv[2] which is installed through pip / requirements.txt to control the node environment. It then has bower commands in tox.ini[3] (though I'd just have a single "bower" environment to implement the tox command I suggest<span style="line-height:19.7999992370605px"> above</span><span style="line-height:1.5">.</span></div><div><br></div><div> </div><div> Richard</div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/StoryBoard">https://wiki.openstack.org/wiki/StoryBoard</a></div><div>[2] <a href="https://pypi.python.org/pypi/nodeenv">https://pypi.python.org/pypi/nodeenv</a></div><div>[3] <a href="https://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/tox.ini">https://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/tox.ini</a></div><div><br></div><br><div class="gmail_quote">On Tue Jan 06 2015 at 11:42:17 AM Tripp, Travis S <<a href="mailto:travis.tripp@hp.com">travis.tripp@hp.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I’m still trying to get the updated library through. I hit a rather difficult workflow:<br>
<br>
<br>
1. Packaged the latest into Xstatic-Angular-1.3.7<br>
2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages<br>
3. Reviewed and approved (after correcting an initial mis-repackaging)<br>
4. Radomir released to Pypi<br>
<br>
This was pretty easy and not too hard. Not too much to complain about.<br>
<br>
However, now, to get Horizon to use it, I have to get that into global requirements. Since I’m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn’t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops:<br>
<br>
<br>
1. Global requirements patch to add angular 1.3.7<br>
* Verify check / recheck fun<br>
* Reviewed and approved<br>
* Gate check / recheck fun<br>
2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages<br>
* Verify check / recheck fun<br>
* Reviewed and approved<br>
* Gate check / recheck fun<br>
3. Global requirements patch to remove deprecated mock and cookies<br>
* Verify check / recheck fun<br>
* Reviewed and approved<br>
* Gate check / recheck fun<br>
<br>
Don’t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements?<br>
<br>
Thanks,<br>
Travis<br>
<br>
From: Richard Jones <<a href="mailto:r1chardj0n3s@gmail.com" target="_blank">r1chardj0n3s@gmail.com</a><<u></u>mailto:<a href="mailto:r1chardj0n3s@gmail.com" target="_blank">r1chardj0n3s@gmail.com</a>><u></u>><br>
Reply-To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack<u></u>-dev@lists.openstack.org</a>>><br>
Date: Monday, January 5, 2015 at 2:08 AM<br>
To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack<u></u>-dev@lists.openstack.org</a>>><br>
Subject: Re: [openstack-dev] [horizon] static files handling, bower/<br>
<br>
<br>
<br>
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski <<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a><<u></u>mailto:<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a>><u></u>> wrote:<br>
On 05/01/15 00:35, Richard Jones wrote:<br>
> On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski<br>
> <<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a><<u></u>mailto:<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a>> <mailto:<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a><u></u><mailto:<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a><u></u>>>> wrote:<br>
><br>
> On 20/12/14 21:25, Richard Jones wrote:<br>
> > This is a good proposal, though I'm unclear on how the<br>
> > static_settings.py file is populated by a developer (as opposed to a<br>
> > packager, which you described).<br>
><br>
> It's not, the developer version is included in the repository, and<br>
> simply points to where Bower is configured to put the files.<br>
> So just to be clear, as developers we:<br>
><br>
> 1. have a bower.json listing the bower component to use,<br>
> 2. use bower to fetch and install those to the bower_components<br>
> directory at the top level of the Horizon repos checkout, and<br>
> 3. manually edit static_settings.py when we add a new bower component to<br>
> bower.json so it knows the appropriate static files to load from that<br>
> component.<br>
><br>
> Is that correct?<br>
><br>
> The above will increase the burden on those adding or upgrading bower<br>
> components (they'll need to check the bower.json in the component for<br>
> the appropriate static files to link in) but will make life easier for<br>
> the re-packagers since they'll know which files they need to cater for<br>
> in static_settings.py<br>
<br>
Well, I expect you can tell Bower to put the files somewhere else than<br>
in the root directory of the project -- a directory like ``bower_files``<br>
or something (that directory is also added to ``.gitignore`` so that you<br>
don't commit it by mistake). Then only that directory needs to be added<br>
to the ``static_settings.py``. Of course, you still need to make all the<br>
``<script>`` links in appropriate places with the right URLs, but you<br>
would have to do that anyways.<br>
<br>
Bower installs into a directory called bower_components in the current directory, which is equivalent to your bower_files above.<br>
<br>
<br>
Let's look at an example. Suppose you need to a new JavaScript library<br>
called "hipster.js". You add it to the ``bower.json`` file, and run<br>
Bower. Bower downloads the right files and does whatever it is that it<br>
does to them, and puts them in ``bower_files/hipster-js``. Now you edit<br>
Horizon's templates and add ``<script src="{{ STATIC_URL<br>
}}/hipster-js/hipster.js">`` to ``_scripts.html``. That's it for you.<br>
Since your ``static_settings.py`` file already has a line:<br>
<br>
('', os.path.join(BASE_DIR, '/bower_files')),<br>
<br>
in it, it will just work.<br>
<br>
Yep, except s/bower_files/bower_components :)<br>
<br>
<br>
Now, suppose that a packager wants to package this for, say, Debian. And<br>
suppose that Debian has "hipster.js" packaged, except it was called<br>
"bro.js" before, and they left the old name for compatibility reasons.<br>
He will look at the change history to the ``bower.json`` and the<br>
``_scripts.html`` files, take the ``static_settings.py`` file for his<br>
distribution, and add a line:<br>
<br>
('hipster-js/hipster.js', '/usr/lib/js_libraries/bro_js/<u></u>bro.js')<br>
<br>
Ah! I had forgotten about that feature. Yep, all good :)<br>
<br>
<br>
Richard<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>