Open Stack

On 15 November 2014 00:58, Radomir Dopieralski <openstack at sheep.art.pl>
wrote:

> On 14/11/14 13:02, Richard Jones wrote:
> > I think that it boils down to whether it'is possible that
> > distributions:
> >
> > 1. package the node-based tools (grunt, karma, protractor, ...) as
> > installable programs, and
> > 2. xstatic-package the bower-based packages that we use (probably a
> > couple of dozen at least).
> >
> > We might even be able to get away without using grunt, though an
> > alternative to its LiveReload facility (and one that doesn't then also
> > depend on another node program like django-livereload does) would be
> > required. I believe tox and django's runserver (and other manage
> > commands) could suffice to replace the other functionality typically
> > provided by grunt.
>
> We don't really need Xstatic for that. The packagers can as well package
> the bower-based packages directly. We can use anything, really,
> as long as we follow a process that makes sure that Horizon can be
> packaged into the different distributions. That is, we need:
>

xstatic provides additional meta-data that makes it much easier to
integrate the static bundle into an application - specifically it
automatically provides the application with file locations and endpoints
needed to be inserted into the application HTML. That stuff would have to
be done manually without xstatic, and would be a configuration pain.



> 1. All dependencies explicit (with tests failing if a dependency is
>    missing),
>

xstatic provides us with a dependency mechanism through standard Python
setuptools facilities.



> 2. explicit version ranges,
>

xstatic is done through requirements.txt, so yep :)



> 3. no multiple versions of the same library,
>

This is not a thing in bower/client-side land. It's really only an issue
for npm-based packages, and as I've mentioned, the things we're using there
should be packaged as tools by the linux vendor, rather than accessed as
packages by our system. Except on non-Linux, of course, where we'll just
use npm ;)

So I guess the big open question is about how distros are going to deal
with npm tool packaging. I can't really answer that question for them
(except to say: don't try to replace npm's dependency solution with your
own; it simply won't work
because you'll probably never find a set of versions that satisfy even just
the few tools we're looking at for this project).


4. additions and upgrades of libraries moderated by the packagers,
>

Is there already some mechanism for handling the creation and management of
xstatic packages and how they interact with linux packagers? Sorry if this
is a noob question.



> 5. ability to replace the development environment with packaged
>    libraries from the system,
>

I would very much like to still use bower for rapid development and
testing, with xstatic coming in once the experimentation is over. But if
there was a tool to automatically generate an xstatic package from a bower
one, that would be eaiser...



> 6. ability to build and test our software with the tools that can be
>    used by all the distributions.
>

Yep, I think that just implies that the xstatic stuff is done, and that the
distros package the few npm tools we use.


On 15 November 2014 01:05, Thomas Goirand <zigo at debian.org> wrote:

> On 11/11/2014 03:02 PM, Richard Jones wrote:
> >     json3
> >     es5-shim
> >     angular
> >     angular-route
> >     angular-cookies
> >     angular-animate
> >     angular-sanitize
> >     angular-smart-table
> >     angular-local-storage
> >     angular-bootstrap
> >     angular-translate
> >     font-awesome
> >     boot
> >     underscore
> >     ng-websocket
>
> Just FYI, in Debian, the libjs-angularjs already carries:
>
> angular-route.js
> angular-cookies.js
> angular-animate.js
> angular-sanitize.js
>
> We also already have packaged:
> font-awesome
> underscore
>
> So, basically, I'd have to package:
> json3
> es5-shim
> boot
> angular-smart-table
> angular-local-storage
> angular-translate
> ng-websocket
>
> That's a reasonable amount of work. Multiply this by 2 for the xstatic
> packages (if we keep using that), that's about 14 new packages.
>

The issue is integration with the Django application. How do we know what
the file path is to the entry point for that that code, and also how it
differs from other packagers? xstatic takes care of that for us (in much
the same way that bower does), so is valuable.



> By the way, can't we use libjs-sockjs instead of ng-websocket?
>

They offer different functionality, as far as I can tell. sockjs is a
compatibility layer thing, I think. I'm not sure. The description is a
little vague. On the other hand, ng-websocket is all about providing an
interface for angular applications over the top of websockets (and a handy
mock).



> Last, I'm ok if we add all these, but please, let's do this in the
> beginning of the Kilo cycle. It was really hard to cope with it at the
> end of the freeze for Juno.
>

I'd imagine this should be reasonable, barring any additional dependencies
we decide to include along the way.


    Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141115/c35fdfdd/attachment.html>