<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 November 2014 09:35, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</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"><div><div>On 11/12/2014 03:03 AM, Matthias Runge 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">
On 12/11/14 08:40, Richard Jones wrote:<br>
<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">
I believe the nodeenv method of installing node solves this, as it's<br>
entirely local to the development environment.<br>
</blockquote>
See below, this touches package build as well.<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">
<br>
I will have to go through all dependencies and do a review, if those are<br>
acceptable for inclusion e.g in Fedora. The same is true for Thomas<br>
Goirand for inclusion in Debian.<br>
<br>
><br>
> Petr Belanyi has added optional jshint install for js linting into<br>
> Horizon and it installs nodejs as it depends on it. Could this approach<br>
> work for our need of js tooling too? [1]<br>
<br>
Sigh, this nonsense doesn't go away? This is the third time the same<br>
issue comes up.<br>
<br>
jshint is NOT free software.<br>
<br>
<a href="https://github.com/jshint/jshint/blob/master/src/jshint.js#L19" target="_blank">https://github.com/jshint/<u></u>jshint/blob/master/src/jshint.<u></u>js#L19</a><br>
<br>
<br>
They're trying to resolve that <a href="https://github.com/jshint/jshint/issues/1234" target="_blank">https://github.com/jshint/<u></u>jshint/issues/1234</a><br>
<br>
But regardless, jshint doesn't have to be installed from a Linux<br>
repository; it's usually installed using npm alongside the other node tools.<br>
<br>
</blockquote>
Thanks for the pointer, this is good news!<br>
<br>
Regarding package managers, my POV is completely different. From a<br>
distributor perspective, where customers expect everything provided from<br>
a single source, I'm not using npm, pip etc. I'm packaging that stuff<br>
properly before using it.<br>
<br>
There are companies out there, where security policy does not allow to<br>
install software from a third party repository. pypi etc. are considered<br>
as a third party here in this context.<br>
<br>
I would prefer to have the complete tool chain available as (RPM)<br>
packages. I am executing unit tests etc. during package build. Our<br>
builders don't have access to the internet, downloading any other stuff<br>
from the internet is no option.<br>
</blockquote>
<br></div></div>
And this is really not-negotiable, too. Debian has the same requirements, it is not Red Hat/Fedora speciufic. It is no different than the Python Code. We dodn't pip install for RHOSP for the Python packages, and we can't use any of the language specific package managers.<br>
<br>
But, we are used to it, and dealing with package dependencies is what we do. Having these in Fedora, while painful, will be ultimately very valuable.<div><div></div></div></blockquote></div><br></div><div class="gmail_extra">I guess a point of difference here is that the Linux packaging systems target global installation, whereas bower and npm (in our case) target a local installation. It's effectively vendoring the code, but you still have to pull it down from a repository for each installation. Don't worry, I'm not going to suggest we actually move back to vendoring :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">We're currently using xstatic and that works with Linux packaging because it was designed to cope with being a global installation. The current Horizon codebase has a django-xstatic plugin which further makes dealing with xstatic components nicer - for example it handles path management and static file compilation (JS minification and concatenation, for example). That's really nice, but poses some problems:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- we would need to xstatic-ify (and deb/rpm-ify) all those components</div><div class="gmail_extra">- we could run into global version conflict issues if we run more than one service on a system - is this likely to be an issue in practise though?</div><div class="gmail_extra">- as far as I'm aware, the xstatic JS minification is not angular-aware, and will break angular code that has not been written to be dumb-minifier-aware (the angular minifier "ngMin" is written in node and knows how to do things more correctly); adding dumb-minifier-awareness to angular code makes it ugly and more error-prone :/</div><div class="gmail_extra"><br></div><div class="gmail_extra">On the minification issue though: I talked to a few people at the summit and we agreed that minification should just be avoided; gzip at the transport layer buys significantly better compression, and has the added bonus that the resultant code is readable. I note that the Debian JS guidelines* only recommend that libraries *should* be minified (though I'm unsure why they even recommend that).</div><div class="gmail_extra"><br></div><div class="gmail_extra">One further note on xstatic vs. bower: during development it's very useful to be able to install random components from bower to try them out; during angboard development I would sometimes install and remove half a dozen components just in one day. I would hope that whatever solution we come up with has at least some of this flexibility for experimentation.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> Richard</div><div class="gmail_extra"><br></div><div class="gmail_extra">* <a href="https://wiki.debian.org/Javascript/Policy">https://wiki.debian.org/Javascript/Policy</a></div><div class="gmail_extra"><br></div></div>