Open Stack

On Tue, Jun 9, 2015 at 3:37 PM Robert Collins <robertc at robertcollins.net>
wrote:

> On 10 June 2015 at 04:01, Michael Krotscheck <krotscheck at gmail.com> wrote:
> > Well, it looks like everyone has disqualified jslint and jshint, so let's
> > just make a decision there and remove them from the running. Unless I
> hear a
> > compelling reason to use something that has the infamous "do no evil"
> > license in it, let's dump it.
> ...
> > As for how this is synchronized, a brief discussion in the infra channel
> > proposed that we put global javascript requirements in the
> > global-requirements repo, and then update the update.py script in that
> repo
> > to also handle bower.json and package.json. Then, if we build an
> eslint/jscs
> > plugin similar to our hacking rules, we can just update that when we
> want to
> > modify the linting rules. Any objections?
>
> Yes, I think this should live in openstack/requirements.
>
> bower.json is clearly js specific; package.json isn't AFAICT - can you
> give me some sane pointers to go level up on that?
>

There are two package managers in the JavaScript world right now, one that
focuses on node.js/server dependencies (karma, lint, express, etc), and one
that focuses on in-browser dependencies (angular, bootstrap, etc). They're
both required for thick browser clients, but for server apps you only
really need package.json

https://docs.npmjs.com/files/package.json
https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json
https://github.com/angular-ui/bootstrap/blob/master/package.json
https://github.com/openstack/horizon/blob/master/package.json


> In the absence of information I'm assuming we should make a subdir
> 'js' and put bower.json and package.json in there (and do the same for
> the python things in a subdir called python for symmetry, though
> backwards compat and tooling considerations may mean that we have to
> prepare for that. The reason being that if package.json is js
> specific, its just confusing to have it live at the top level. Also we
> may want to call them global-$thing, since if we do have js in the
> requirements repo itself at some point, it would be good not to
> conflict on names.
>

FYI, it looks like the monasca team may want to start doing similar things
with Java. More information after I hunt them down this morning :)


> I'm not at all sure that update.py should handle the json files per
> se; will the policy for those files be the same as we use for python?
>

Add linting rule sets to this list, contained either in .jscsrc or
.eslintrc. Javascript does not have the privilege of pep8 being baked into
the language tooling, so we have to sync it ourselves.


> If not it might be cleaner to have a new entry point. OTOH I'll need
> to look closely at a few real {bower,package}.json files to proffer an
> useful opinion. [Perhaps you covered this in IRC - it didn't come
> through in your summary].
>

It depends on what you think update.py is supposed to do. If I look at that
repository, I would argue that the purpose is to "Synchronize common files
and properties across registered openstack projects". In this case, a
"requirement" is defined as something required to meet a minimum set of
project "sanity" standards.

Also, I'm in the middle of rearranging update.py to handle PEP 426 and so
> we should probably coordinate so we don't tromp on each other.
>

Do you have a patch?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150610/1c9cd361/attachment.html>