Open Stack

On 14/11/14 13:02, Richard Jones wrote:
>> On 14 November 2014 18:51, Radomir Dopieralski <openstack at sheep.art.pl
>> <mailto:openstack at sheep.art.pl>> wrote:
>>     On 13/11/14 23:30, Martin Geisler wrote:
[...]

>>     > 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.

[...]

>>     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.

[...]


> 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:

1. All dependencies explicit (with tests failing if a dependency is
   missing),
2. explicit version ranges,
3. no multiple versions of the same library,
4. additions and upgrades of libraries moderated by the packagers,
5. ability to replace the development environment with packaged
   libraries from the system,
6. ability to build and test our software with the tools that can be
   used by all the distributions.

As I said, this is more of a process thing than a tool thing -- I
believe any tool can be used to follow this process, more or less
automatically.

-- 
Radomir Dopieralski