[openstack-dev] [Horizon] the future of angularjs development in Horizon
jtomasek at redhat.com
Thu Nov 13 16:27:14 UTC 2014
On 11/13/2014 04:04 PM, Thomas Goirand wrote:
> On 11/13/2014 12:13 PM, Richard Jones wrote:
>> the npm stuff is all tool chain; tools
>> that I believe should be packaged as such by packagers.
> npm is already in Debian:
> However, just like we can't use CPAN, "pear install", "pip install" and
> such when building or installing package, we wont be able to use NPM.
> This means every single dependency that isn't in Debian will need to be
>> Horizon is an incredibly complex application. Just so we're all on the
>> same page, the components installed by bower for angboard are:
>> Because writing an application the size of Horizon without it would be
>> madness :)
>> Provides structure to the application through URL routing.
>> Provides management of browser cookies in a way that integrates well
>> with angular.
>> Allows direct embedding of HTML into angular templates, with sanitization.
>> Compatibility for older browsers so JSON works.
>> Table management (population, sorting, filtering, pagination, etc)
>> Browser local storage with cookie fallback, integrated with angular
>> Extensions to angular that leverage bootstrap (modal popups, tabbed
>> displays, ...)
>> Additional glyphs to use in the user interface (warning symbol, info
>> symbol, ...)
>> Bootstrap for CSS styling (this is the dependency that brings in
>> jquery and requirejs)
>> lacks but Python programmers expect.
>> Angular-friendly interface to using websockets
>> Support for localization in angular using message catalogs generated
>> by gettext/transifex.
>> Mocking support for unit testing angular code
>> More support for angular unit tests
>> Additionally, angboard vendors term.js because it was very poorly
>> packaged in the bower ecosystem. +1 for xstatic there I guess :)
>> So those are the components we needed to create the prototype in a few
>> weeks. Not using them would have added months (or possibly years) to the
>> development time. Creating an application of the scale of Horizon
>> without leveraging all that existing work would be like developing
>> OpenStack while barring all use of Python 3rd-party packages.
> I have no problem with adding dependencies. That's how things work, for
> sure, I just want to make sure it doesn't become hell, with so many
> components inter-depending on 100s of them, which would become not
> manageable. If we define clear boundaries, then fine! The above seems
> reasonable anyway.
> Though did you list the dependencies of the above?
> Also, if the Horizon project starts using something like NPM (which
> again, is already available in Debian, so it has my preference), will we
> at least be able to control what version gets in, just like with pip?
> Because that's a huge concern for me, and this has been very well and
> carefully addressed during the Juno cycle. I would very much appreciate
> if the same kind of care was taken again during the Kilo cycle, whatever
> path we take. How do I use npm by the way? Any pointer?
NPM and Bower work the similar way as pip, they maintain similar files
as requirements.txt that list dependencies and it's versions.
I think we should bring up patch that introduces this toolset so we can
discuss the real amount of dependencies and the process.
It would be also nice to introduce something similar as
global-requirements.txt in OpenStack project to make sure we have all
deps in one place and get some approval process on versions used.
Here is an example of random Angular application's package.json (used by
NPM) and bower.json (used by Bower) files:
I'll try to search for a good article that describes how this ecosystem
> Thomas Goirand (zigo)
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev