Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-21 Thread david . comay

As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch Horizon -- the patch that is prepared
for that specific library and applied system-wide is sufficient.


But for distributions that package Horizon itself, don't they
effectively need to patch Horizon? Namely, don't they need to install
on their build systems fixed JavaScript distribution packages to
address the security issue and then they need to rebuild Horizon itself
even if there are no Horizon source code changes.


From a Horizon end-user perspective who relies on the distribution's

packages to get Horizon, they'll get the security fix but it seems
distributors will still need to rebuild and deliver Horizon for every
upstream JavaScript fix whether the files come from XStatic, Bower, or
some other method.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-14 Thread david . comay

I won't stop to comment on this statement other than to say Javascript is
quite relevant to Oracle, Oracle's customers, and Oracle's partners.

Your argument is a boondoggle. Refusing to use node because your favorite
platform doesn't support it is not the fault of node.js, it's the fault of
the platform.


Not to belabor the thread, but yes, of course JavaScript is very
relevant to Oracle, Solaris, our customers/partners, etc. And that
includes both client and server-side. As Drew stated, as of this moment
we haven't yet made Node.js available on SPARC but I expect that to
change in the future. But the question or potential concern remains as
to whether adding a non-Python/pip build dependency makes sense.

I'm not particularly well-versed in the Horizon build process so
perhaps I'm way off base. But given that a distribution's Horizon build
package embeds various JavaScript libraries to be used by the browser,
how those libraries are obtained during the build process is an
interesting build detail. I thought the intent of the XStatic work was
to provide Python wrappers around the various JavaScript libraries so
they could be pulled down via pip. Since there's already a Python
requirements.txt file for versioning information, that seemed to be a
nice way of indicating which versions of the JavaScript libraries could
be used by Horizon and Python was used all the way through the build.

I realize that it takes work to build the XStatic packages but given
the Python packages are basically wrappers, it seems creating those and
uploading them to pypi could be automated by using Bower and setup.py
but perhaps translating the metadata isn't straightforward.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev