<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 9, 2015 at 3:37 PM Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10 June 2015 at 04:01, Michael Krotscheck <<a href="mailto:krotscheck@gmail.com" target="_blank">krotscheck@gmail.com</a>> wrote:<br>
> Well, it looks like everyone has disqualified jslint and jshint, so let's<br>
> just make a decision there and remove them from the running. Unless I hear a<br>
> compelling reason to use something that has the infamous "do no evil"<br>
> license in it, let's dump it.<br>
...<br>
> As for how this is synchronized, a brief discussion in the infra channel<br>
> proposed that we put global javascript requirements in the<br>
> global-requirements repo, and then update the update.py script in that repo<br>
> to also handle bower.json and package.json. Then, if we build an eslint/jscs<br>
> plugin similar to our hacking rules, we can just update that when we want to<br>
> modify the linting rules. Any objections?<br>
<br>
Yes, I think this should live in openstack/requirements.<br>
<br>
bower.json is clearly js specific; package.json isn't AFAICT - can you<br>
give me some sane pointers to go level up on that?<br></blockquote><div><br></div><div>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</div><div><div><br class="Apple-interchange-newline"><a href="https://docs.npmjs.com/files/package.json">https://docs.npmjs.com/files/package.json</a><br></div><div><a href="https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json">https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json</a><br></div><div><a href="https://github.com/angular-ui/bootstrap/blob/master/package.json">https://github.com/angular-ui/bootstrap/blob/master/package.json</a><br></div><div><a href="https://github.com/openstack/horizon/blob/master/package.json">https://github.com/openstack/horizon/blob/master/package.json</a><br></div><div> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the absence of information I'm assuming we should make a subdir<br>
'js' and put bower.json and package.json in there (and do the same for<br>
the python things in a subdir called python for symmetry, though<br>
backwards compat and tooling considerations may mean that we have to<br>
prepare for that. The reason being that if package.json is js<br>
specific, its just confusing to have it live at the top level. Also we<br>
may want to call them global-$thing, since if we do have js in the<br>
requirements repo itself at some point, it would be good not to<br>
conflict on names.<br></blockquote><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not at all sure that update.py should handle the json files per<br>
se; will the policy for those files be the same as we use for python?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If not it might be cleaner to have a new entry point. OTOH I'll need<br>
to look closely at a few real {bower,package}.json files to proffer an<br>
useful opinion. [Perhaps you covered this in IRC - it didn't come<br>
through in your summary].<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>Do you have a patch?</div><div><br></div><div>Michael </div></div></div>