Open Stack

On 18/11/14 00:59, Richard Jones wrote:
> On 17 November 2014 21:54, Radomir Dopieralski <openstack at sheep.art.pl
> <mailto:openstack at 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