On 18/11/14 00:59, Richard Jones wrote: > On 17 November 2014 21:54, Radomir Dopieralski <openst...@sheep.art.pl > <mailto:openst...@sheep.art.pl>> wrote:
>> - Bower in the development environment, >> - Bower configuration file in two copies, one for global-requirements, >> and one for the Horizon's local requirements. Plus a gate job that makes >> sure no new library or version gets included in the Horizon's before >> getting into the global-requirements, > > Could you perhaps elaborate on this? How do you see the workflow working > here? Basically we would have an additional file in the global-requirements directory, for listing the JavaScript dependencies. Then we would have a check on the Horizon's gate that would check Horizon's Bower configuration against that global-requirements file. This way we keep the same process for JavaScript libraries as we have for Python libraries: first you submit a patch to the global-requirements and have the dependency accepted by the infra team and packagers (checked against licenses, version conflicts, etc.), and then you add it to Horizon's dependencies. Of course you can submit both patches at once, just the Horizon one will fail the gate until the global-requirements one gets merged. > 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 > http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html If we use Bower, we don't need to use Xstatic. It would be pure overhead. Bower already takes care of tracking releases and versions, and of bundling the files. All we need is a simple line in the settings.py telling Django where it puts all the files -- we don't really need Xstatic just for that. The packagers can then take those Bower packages and turn them into system packages, and just add/change the paths in settings.py to where they put the files. All in one place. > I will be looking into creating such a tool today. The problem is not the work that has to be done for the initial creation of the package. That is one-time effort and as you show, it can be easily automated. The problem is the effort and resources needed to maintain that package. Someone (the author of the package?) has to check for security vulnerabilities, critical bugs, packaging issues, changing licenses, etc. and patch/update the packages accordingly. Also, the more layers of code you have, them more likely you are to have bugs in the. Again, I see no reason to duplicate the effort if the Bower packagers are doing that work for us already (they are, are they?). -- Radomir Dopieralski _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
