<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 November 2014 00:58, Radomir Dopieralski <span dir="ltr"><<a href="mailto:openstack@sheep.art.pl" target="_blank">openstack@sheep.art.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 14/11/14 13:02, Richard Jones wrote:<br></span><span class="">> I think that it boils down to whether it'is possible that<br>
> distributions:<br>
><br>
> 1. package the node-based tools (grunt, karma, protractor, ...) as<br>
> installable programs, and<br>
> 2. xstatic-package the bower-based packages that we use (probably a<br>
> couple of dozen at least).<br>
><br>
> We might even be able to get away without using grunt, though an<br>
> alternative to its LiveReload facility (and one that doesn't then also<br>
> depend on another node program like django-livereload does) would be<br>
> required. I believe tox and django's runserver (and other manage<br>
> commands) could suffice to replace the other functionality typically<br>
> provided by grunt.<br>
<br>
</span>We don't really need Xstatic for that. The packagers can as well package<br>
the bower-based packages directly. We can use anything, really,<br>
as long as we follow a process that makes sure that Horizon can be<br>
packaged into the different distributions. That is, we need:<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">1. All dependencies explicit (with tests failing if a dependency is<br>
missing),<br></blockquote><div><br></div><div>xstatic provides us with a dependency mechanism through standard Python setuptools facilities.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. explicit version ranges,<br></blockquote><div><br></div><div>xstatic is done through requirements.txt, so yep :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. no multiple versions of the same library,<br></blockquote><div><br></div><div>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 ;)</div><div><br></div><div>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<br>because you'll probably never find a set of versions that satisfy even just the few tools we're looking at for this project).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4. additions and upgrades of libraries moderated by the packagers,<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
5. ability to replace the development environment with packaged<br>
libraries from the system,<br></blockquote><div><br></div><div>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...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
6. ability to build and test our software with the tools that can be<br>
used by all the distributions.<br></blockquote><div><br></div><div>Yep, I think that just implies that the xstatic stuff is done, and that the distros package the few npm tools we use.</div><div><br></div><div><br></div><div>On 15 November 2014 01:05, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 11/11/2014 03:02 PM, Richard Jones wrote:<br></span><span class="">> json3<br>> es5-shim<br>> angular<br>> angular-route<br>> angular-cookies<br>> angular-animate<br>> angular-sanitize<br>> angular-smart-table<br>> angular-local-storage<br>> angular-bootstrap<br>> angular-translate<br>> font-awesome<br>> boot<br>> underscore<br>> ng-websocket<br><br></span>Just FYI, in Debian, the libjs-angularjs already carries:<br><br>angular-route.js<br>angular-cookies.js<br>angular-animate.js<br>angular-sanitize.js<br><br>We also already have packaged:<br>font-awesome<br>underscore<br><br>So, basically, I'd have to package:<br>json3<br>es5-shim<br>boot<br>angular-smart-table<br>angular-local-storage<br>angular-translate<br>ng-websocket<br><br>That's a reasonable amount of work. Multiply this by 2 for the xstatic<br>packages (if we keep using that), that's about 14 new packages.<br></blockquote><div><br></div><div><div>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.</div><div> </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">By the way, can't we use libjs-sockjs instead of ng-websocket?<br></blockquote><div><br></div><div>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).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Last, I'm ok if we add all these, but please, let's do this in the<br>beginning of the Kilo cycle. It was really hard to cope with it at the<br>end of the freeze for Juno.<br></blockquote><div><br></div><div>I'd imagine this should be reasonable, barring any additional dependencies we decide to include along the way.</div><div><br></div><div><br></div></div><div> Richard</div></div></div></div>