Hello, 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 settings.py file; * 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? -- Radomir Dopieralski _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev