This is a good proposal, though I'm unclear on how the static_settings.py file is populated by a developer (as opposed to a packager, which you described).<br><div><br></div><div><br></div><div>     Richard</div><br><div class="gmail_quote">On Fri Dec 19 2014 at 12:59:37 AM Radomir Dopieralski <<a href="mailto:openstack@sheep.art.pl">openstack@sheep.art.pl</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
revisiting the package management for the Horizon's static files again,<br>
I would like to propose a particular solution. Hopefully it will allow<br>
us to both simplify the whole setup, and use the popular tools for the<br>
job, without losing too much of benefits of our current process.<br>
<br>
The changes we would need to make are as follows:<br>
<br>
* get rid of XStatic entirely;<br>
* add to the repository a configuration file for Bower, with all the<br>
required bower packages listed and their versions specified;<br>
* add to the repository a static_settings.py file, with a single<br>
variable defined, STATICFILES_DIRS. That variable would be initialized<br>
to a list of pairs mapping filesystem directories to URLs within the<br>
/static tree. By default it would only have a single mapping, pointing<br>
to where Bower installs all the stuff by default;<br>
* add a line "from static_settings import STATICFILES_DIRS" to the<br>
settings.py file;<br>
* add jobs both to run_tests.sh and any gate scripts, that would run Bower;<br>
* add a check on the gate that makes sure that all direct and indirect<br>
dependencies of all required Bower packages are listed in its<br>
configuration files (pretty much what we have for requirements.txt now);<br>
<br>
That's all. Now, how that would be used.<br>
<br>
1. The developers will just use Bower the way they would normally use<br>
it, being able to install and test any of the libraries in any versions<br>
they like. The only additional thing is that they would need to add any<br>
additional libraries or changed versions to the Bower configuration file<br>
before they push their patch for review and merge.<br>
<br>
2. The packagers can read the list of all required packages from the<br>
Bower configuration file, and make sure they have all the required<br>
libraries packages in the required versions.<br>
<br>
Next, they replace the static_settings.py file with one they have<br>
prepared manually or automatically. The file lists the locations of all<br>
the library directories, and, in the case when the directory structure<br>
differs from what Bower provides, even mappings between subdirectories<br>
and individual files.<br>
<br>
3. Security patches need to go into the Bower packages directly, which<br>
is good for the whole community.<br>
<br>
4. If we aver need a library that is not packaged for Bower, we will<br>
package it just as we had with the XStatic packages, only for Bower,<br>
which has much larger user base and more chance of other projects also<br>
using that package and helping with its testing.<br>
<br>
What do you think? Do you see any disastrous problems with this system?<br>
--<br>
Radomir Dopieralski<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>