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.
   Compatibility for older browsers so Javascript (ECMAScript 5) 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)
    Javascript utility library providing a ton of features Javascript
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 works.


Thomas Goirand (zigo)

OpenStack-dev mailing list


OpenStack-dev mailing list

Reply via email to