[openstack-dev] [horizon] static files handling, bower/
openstack at sheep.art.pl
Thu Dec 18 13:58:07 UTC 2014
revisiting the package management for the Horizon's static files again,
I would like to propose a particular solution. Hopefully it will allow
us to both simplify the whole setup, and use the popular tools for the
job, without losing too much of benefits of our current process.
The changes we would need to make are as follows:
* get rid of XStatic entirely;
* add to the repository a configuration file for Bower, with all the
required bower packages listed and their versions specified;
* add to the repository a static_settings.py file, with a single
variable defined, STATICFILES_DIRS. That variable would be initialized
to a list of pairs mapping filesystem directories to URLs within the
/static tree. By default it would only have a single mapping, pointing
to where Bower installs all the stuff by default;
* add a line "from static_settings import STATICFILES_DIRS" to the
* add jobs both to run_tests.sh and any gate scripts, that would run Bower;
* add a check on the gate that makes sure that all direct and indirect
dependencies of all required Bower packages are listed in its
configuration files (pretty much what we have for requirements.txt now);
That's all. Now, how that would be used.
1. The developers will just use Bower the way they would normally use
it, being able to install and test any of the libraries in any versions
they like. The only additional thing is that they would need to add any
additional libraries or changed versions to the Bower configuration file
before they push their patch for review and merge.
2. The packagers can read the list of all required packages from the
Bower configuration file, and make sure they have all the required
libraries packages in the required versions.
Next, they replace the static_settings.py file with one they have
prepared manually or automatically. The file lists the locations of all
the library directories, and, in the case when the directory structure
differs from what Bower provides, even mappings between subdirectories
and individual files.
3. Security patches need to go into the Bower packages directly, which
is good for the whole community.
4. If we aver need a library that is not packaged for Bower, we will
package it just as we had with the XStatic packages, only for Bower,
which has much larger user base and more chance of other projects also
using that package and helping with its testing.
What do you think? Do you see any disastrous problems with this system?
More information about the OpenStack-dev