Open Stack

Matthias Runge <mrunge at redhat.com> writes:

> On Wed, Nov 12, 2014 at 08:35:18AM -0500, Monty Taylor wrote:
>> Just for the record, I believe that we should chose the tools that
>> make sense for making our software, as long as it's not physically
>> impossible for them to be packaged. This means we should absolutely
>> not use things that require multiple versions of node to be needed.
>> The nodejs that's in trusty is new enough to work with all of the
>> modern javascript tool chain things needed for this, so other than
>> the various javascript tools and libraries not being packaged in the
>> distros yet, it should be fine.
>
> Agreed. We're in the position to describe or define, what we'd like to
> use or to see in the future. That may require us to create required
> tools.
>
> You're not concerned about node.js? Most probably, since you're not
> distributing it. Looking at the changelog, I'm a bit worried[1]:
>
> [...]

For better or for worse, the JavaScript community is using Node,
Grunt/Gulp, bower, ... as the default infrastructure tools.

Not using them or putting effort into creating alternatives would be
working against that community and I would say it's wasted effort. That
effort could be put to better use in the core OpenStack code.

I haven't cared much about Node itself, it's just a VM that runs my
JavaScript code. If I were to deploy it on a server I would agree that
the security and robustness becomes critical.

I find npm and bower alright -- they do their job just fine. The
"semantic versioning" craze is strange to me, but you can avoid it by
fully specifying the versions you depend on.

I find Grunt and Gulp to be overrated. My very simple Gruntfile[1] now
has about 170 lines of JSON to configure the simple tasks. For a "copy
this to that" task, the JSON format is fine, but for more complex tasks
with several steps it feels forced. I mean, I need to copy files in
several tasks, so I end up with

  copy: {
      some_target: {
          ...
      },
      other_target: {
          ...
      }
  }

in one part of the Gruntfile and then

  task: {
      some_target: {
          ...
      }
  }

many lines away. There's nothing to connect the two pieces of
configuration than a third task that runs both.

The whole multi-task idea also seems strange to me. It feels like an
idea that felt nice when the system was small and now the entire system
is built around it. As an example, running 'grunt copy' by itself is
useless when the two copy targets are small parts of bigger tasks.


About Gulp... I don't get it and I don't buy it :) The implication that
using streams will make your build fast is at best an
over-simplification. While streaming data is cool, elevating this single
idea to the fundamental building block in a simple task runner seems
contrieved.

It forces you into a pattern and you end up writing code looking like:

  gulp.src('./client/templates/*.jade')
    .pipe(jade())
    .pipe(gulp.dest('./build/templates'))
    .pipe(minify())
    .pipe(gulp.dest('./build/minified_templates'));

That might look cute for a minimal example like this, but I bet it'll
make things harder than they should be in the future. As in, how can I
inject more files into the stream conditionally? How do I read an
environment variable and inject some extra files? With normal JavaScript
I would know how to do this.

(Here I would apparently use gulp-if together with something called a
lazypipe and I would still need to somehow insert the extra files in the
stream.)

[1]: https://github.com/zerovm/swift-browser/blob/master/Gruntfile.js

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/50fcf28c/attachment.pgp>