Open Stack

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.


    Richard

On 14 November 2014 18:51, Radomir Dopieralski <openstack at sheep.art.pl>
wrote:

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