Globally-installed linter used instead of local copy

[tdrews]

It appears that running the linter on Cygwin produces more errors (false positives?) than on Linux. For example, see #144.

[joeyparrish]

@jonoward I am unable to reproduce this on my cygwin system. I tried with git's core.autocrlf option unset, set to true, and set to false. With each setting, I did a fresh clone of the sources and then ran ./build/lint.sh, and all three times I got 0 errors.

If you can still reproduce this, can you please send me a tarball of your working tree for comparison?

[jonoward]

I've got latest master with no modifications and I can still repro. Here is my working tree + linter output: https://dl.dropboxusercontent.com/u/42310035/shaka-master.tar.gz

Perhaps it's something environmental with my Cygwin setup, could I be on an older version of Closure? Or is everything contained within the working tree?

[joeyparrish]

Basically everything but bash, python, and java is contained within the working tree, including compiler & linter. I'll try with your tarball and see if I can repro. If so, I'll dissect the differences between your working tree and my own. Otherwise, we can try to debug and find the environmental difference. Thanks!

[joeyparrish]

Looks like a newline problem. Your whole repo has a different newline style than mine. I'm getting 8MB from "git diff". :-)

What tools are you using? Are you using the cygwin version of git?

There's a .gitattributes file to force unix-style newlines, but in your case, it appears not to have worked. I'm wondering if you have a checkout that predates that file or if it was otherwise ignored somehow. If you do a fresh clone of the repository, does this linter problem go away?

[joeyparrish]

Actually, I'm getting no linter errors even with the DOS newlines. Since the linter is written in python, perhaps its your python implementation? Are you using the cygwin version of python?

[jonoward]

Yup I'm using the Cygwin version of Python, version 2.7.5-3. Which are you using?

[joeyparrish]

Sorry for the delay. I missed this in my inbox. I'm running cygwin python 2.7.10.

[jonoward]

I think I've figured out what has happened. It seems I had a globally installed package for closure_linter in C:\cygwin64\lib\python2.7\site-packages which was being used in place of the package within the working tree. I'm not sure what installed this package, but it appeared to be an older version than the one in the working tree. I uninstalled all python related cygwin packages, deleted C:\cygwin64\lib\python2.7\ and reinstalled everything, and now the linter is reporting zero errors as expected on latest master. So seems to be environmental. Cheers

[joeyparrish]

Ah, I see. Do we need to change the way we import the package to make sure the local copy is used?

[joeyparrish]

Never mind, I think the answer is yes. In gjslint:

sys.path.append(gflags_path)
sys.path.append(linter_path)

Those should probably be prepended instead.

[jonoward]

Yup good point, prepending to the path would have probably resolved it...

[joeyparrish]

Reproduced on Linux by globally installing closure_linter and then breaking it:

sudo pip install https://closure-linter.googlecode.com/svn/trunk/
sudo rm /usr/local/lib/python2.7/dist-packages/closure_linter/*.pyc
sudo bash -c 'for i in /usr/local/lib/python2.7/dist-packages/closure_linter/*.py; do
  echo None > $i
done'

[joeyparrish]

Okay, this is now fixed. Sorry it took me so long to recognize the real problem, and thanks both for the report and your help debugging.