<div dir="ltr">I think that it boils down to whether it'is possible that distributions:<div><div><br></div><div>1. package the node-based tools (grunt, karma, protractor, ...) as installable programs, and</div><div>2. xstatic-package the bower-based packages that we use (probably a couple of dozen at least).</div><div><br></div><div>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.</div><div><br></div></div><div><br></div><div>    Richard</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 November 2014 18:51, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13/11/14 23:30, Martin Geisler wrote:<br>
<br>
[...]<br>
<span class=""><br>
> While I agree that it's chaotic, I also think you make the problem worse<br>
> than it really is. First, remember that the user who installs Horizon<br>
> won't need to use the JavaScript based *developer* tools such as npm,<br>
> bower, etc.<br>
><br>
> That is, I think Horizon developers will use these tools to produce a<br>
> release -- a tarball -- and that tarball will be something you unpack on<br>
> your webserver and then you're done. I base this on what I've seen in<br>
> the project I've been working. The release tarball you download here<br>
> don't mention npm, bower, or any of the other tools:<br>
><br>
>   <a href="https://github.com/zerovm/swift-browser/releases" target="_blank">https://github.com/zerovm/swift-browser/releases</a><br>
><br>
> The tools were used to produce the tarball and were used to test it, but<br>
> they're not part of the released product. Somewhat similar to how GCC<br>
> isn't included in the tarball if you download a pre-compiled binary.<br>
<br>
</span>[...]<br>
<span class=""><br>
> Maybe a difference is that you don't (yet) install a web application<br>
> like you install a system application. Instead you *deploy* it: you<br>
> unpack files on a webserver, you configure permissions, you setup cache<br>
> rules, you configure a database, etc.<br>
<br>
</span>[...]<br>
<br>
I think I see where the misunderstanding is in this whole discussion. It<br>
seems it revolves around the purpose and role of the distribution.<br>
<br>
>From the naive point of view, the role of a Linux distribution is to<br>
just collect all the software from respective upstream developers and<br>
put it in a single repository, so that it can be easily installed by the<br>
users. That's not the case.<br>
<br>
The role of a distribution is to provide a working ecosystem of<br>
software, that is:<br>
a) installed and configured in consistent way,<br>
b) tested to work with the specific versions that it ships with,<br>
c) audited for security,<br>
d) maintained, including security patches,<br>
e) documented, including external tutorials and the like,<br>
f) supported, either by the community or by the companies that provide<br>
support,<br>
g) free of licensing issues and legal risks as much as possible,<br>
h) managed with the common system management tools.<br>
<br>
In order to do that, they can't just take a tarball and drop it in a<br>
directory. They always produce their own builds, to make sure it's the<br>
same thing that the source code specifies. They sometimes have to<br>
rearrange configuration files, to make them fit the standards in their<br>
system. They provide sane configuration defaults. They track the<br>
security reports about all the installed components, and apply fixes,<br>
often before the security issue is even announced.<br>
<br>
Basically, a distribution adds a whole bunch of additional guarantees<br>
for the software they ship. Those are often long-term guarantees, as<br>
they will be supporting our software long after we have forgotten about<br>
it already.<br>
<br>
You say that "web development doesn't work like that". That may be true,<br>
but that's mostly because if you develop a new web application in-house,<br>
and deploy it on your server, you don't really have such large legal<br>
risk, configuration complexity or support problem -- you just have to<br>
care about that single application, because the packagers from the<br>
distribution that you are using are taking care about all the rest of<br>
software on your server.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Radomir Dopieralski<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>