On 11/11/14 08:02, Richard Jones wrote:

[...]

> There were some discussions around tooling. We're using xstatic to
> manage 3rd party components, but there's a lot missing from that
> environment. I hesitate to add supporting xstatic components on to the
> already large pile of work we have to do, so would recommend we switch
> to managing those components with bower instead. For reference the list
> of 3rd party components I used in angboard* (which is really only a
> teensy fraction of the total application we'd end up with, so this
> components list is probably reduced):

[...]

> Just looking at PyPI, it looks like only a few of those are in xstatic,
> and those are out of date.

There is a very good reason why we only have a few external JavaScript
libraries, and why they are in those versions.

You see, we are not developing Horizon for our own enjoyment, or to
install it at our own webserver and be done with it. What we write has
to be then packaged for different Linux distributions by the packagers.
Those packagers have very little wiggle room with respect to how they
can package it all, and what they can include.

In particular, libraries should get packaged separately, so that they
can upgrade them and apply security patches and so on. Before we used
xstatic, they have to go through the sources of Horizon file by file,
and replace all of our bundled files with symlinks to what is provided
in their distribution. Obviously that was laborious and introduced bugs
when the versions of libraries didn't match.

So now we have the xstatic system. That means, that the libraries are
explicitly listed, with their minimum and maximum version numbers, and
it's easy to make a "dummy" xstatic package that just points at some
other location of the static files. This simplifies the work of the
packagers.

But the real advantage of using the xstatic packages is that in order to
add them to Horizon, you need to add them to the global-requirements
list, which is being watched and approved by the packagers themselves.
That means, that when you try to introduce a new library, or a version
of an old library, that is for some reason problematic for any of the
distributions (due to licensing issues, due to them needing to remain at
an older version, etc.), they get to veto it and you have a chance of
resolving the problem early, not dropping it at the last moment on the
packagers.

Going back to the versions of the xstatic packages that we use, they are
so old for a reason. Those are the newest versions that are available
with reasonable effort in the distributions for which we make Horizon.

If you want to replace this system with anything else, please keep in
contact with the packagers to make sure that the resulting process makes
sense and is acceptable for them.

-- 
Radomir Dopieralski


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to