-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vulture and pylint failing #73
Comments
@hschilling use the prospector argument |
Hi Jeff, Thanks for the suggestion. Maybe our project size is stretching the limits ? Thanks for the help Traceback (most recent call last): On Dec 4, 2014, at 6:42 PM, Jeff Quast <notifications@github.commailto:notifications@github.com> wrote: @hschillinghttps://github.com/hschilling use the prospector argument --die-on-tool-error and it may help discover the root issue — Herb Schilling |
Suggest this issue be closed, prospector can't help you much here. However I filed a bug on your behalf with astroid: https://bitbucket.org/logilab/astroid/issue/65/oserror-errno-24-too-many-open-files you may watch this issue for any resolution or response. In the meantime, I suggest finding a way to increase the number of open files for your user account. |
Hi, I see. Thanks for filing that bug for me. I did try ( I am using Mac OS X 10.8.5 ) sudo launchctl limit maxfiles 1000000 1000000 and got the same error. I monitored the process using Activity Monitor's Open Files pane and I saw that it just kept growing as it opened up source files but it sure didn't look like 1000000 files in there ! On Dec 6, 2014, at 6:34 PM, Jeff Quast <notifications@github.commailto:notifications@github.com> Suggest this issue be closed, prospector can't help you much here. However I filed a bug on your behalf with astroid: https://bitbucket.org/logilab/astroid/issue/65/oserror-errno-24-too-many-open-files you may watch this issue for any resolution or response. In the meantime, I suggest finding a way to increase the number of open files for your user account. — Herb Schilling |
That doesn't work for some reason. Just type: $ ulimit -n 16384 on your shell. 1000000 is also too high, 16384 is the actual upperbound limit? |
This was fixed upstream, Pylint 1.4.1 should resolve the issue. prospector is currently bound to |
If you are interested, I have a cheap workaround for installing and running prospector using tox, removing the upperbound, and upgrading pylint and astroid: tox.ini excerpt:
requirements-analysis.txt
|
Hi Jeff, Thanks for this and also for letting me know about the fix to Pylint ! On Dec 15, 2014, at 11:53 AM, Jeff Quast <notifications@github.commailto:notifications@github.com> wrote: If you are interested, I have a cheap workaround for installing and running prospector using tox, removing the upperbound, and upgrading pylint and astroid: tox.ini excerpt: [testenv:prospector] cheap workaround until prospector's next release#75commands = pip install --upgrade astroid pylint requirements-analysis.txt prospector[with_dodgy,with_frosted,with_mccabe,with_pep257,with_pep8,with_pylint,with_pyroma,with_vulture] — Herb Schilling |
Finally got around to making a 0.8 release, sorry about the delay. #10 and #74 turned out to be a bit more fiddly than expected. Let me know if this fixes these issues - it should do as @jquast by the way you can use |
@hschilling if you upgrade to prospector 0.8, this should hopefully fix your issue. |
Thanks ! Will give it a try over the weekend |
I tried it. I did install everything using: pip install prospector[with_everything] When I just do prospector in a directory with a super simple Python script, it works. If I do the same in our OpenMDAO project directory, I get this. Traceback (most recent call last): The value that gets returned from autodetect_libraries(self.workdir) is:
Let me know if I should try something else. Sorry! |
I'm submitting a PR for this shortly, this broke for me too |
submitted new issue #82 for tracking |
Fixed in PR #85 |
Thanks! I tried it again and things are working much better. The only problem left is I see this in the output at the top of the output file. I ran this with --with-tool pyroma --with-tool vulture. There is nothing in the output that tells me more about the exception. I can seem to run pylint and pyroma without errors Messages. |
Don't forget, use argument |
@hschilling I tried this myself on the OpenMDAO-Framework repository and pylint worked fine, so if you could use Pyroma fails because one of the |
Sorry, I DID forget about --die-on-tool-error :-) Pylinit dies with "RuntimeError: maximum recursion depth exceeded" Here is most of the stack trace. I cut out the part where it has a LOT of these lines repeated over and over again. File "/Users/herbertschilling/Documents/OpenMDAO/dev/latest/devenv/lib/python2.7/site-packages/astroid/bases.py", line 341, in wrapped Traceback (most recent call last): |
BTW, the usage: output for prospector looks like it could be tweaked. Missing --die-on-tool-error and the alternate ways of using --with-tool,etc... usage: prospector [-h] [-0] [-A] [-u USES] [-B] [--no-common-plugin] [-D] [-T] |
I do have numpy installed. This is why pyroma dies for me. Looks like you just need to use if '_setuptools' in data: instead of if data['_setuptools']: In fact, if I make that code change, everything runs for me if I --without-tool pylint Traceback (most recent call last): and data is equal to (Pdb) data |
@hschilling I've seen the recursion depth thing before but I think in an older version of astroid. Can you do a 'pip freeze' and show the versions of astroid, logilab-common and pylint? For pyroma, it's the same stacktrace as the one I got, but the problem is in pyroma itself, so I'll need to make a PR on that. |
@carlio Thanks. Here is the output of pip freeze: Cython==0.20.1 |
@hschilling thanks, unfortunately those are exactly the versions I was using so that's not the issue. I tried it again on my Mac this time, and I get a similar problem - I don't get a stacktrace but prospector is taking forever and when I Ctrl-C I see a very deep stacktrace at the same point you did. This doesn't happen on my Ubuntu machine. Very odd. Out of interest, how long does it take to get the stacktrace? |
47 seconds |
It just finished for me, and no stack trace or problem. I'm 100% baffled why it's not working for you. |
Wait, ignore that! Of course, if I don't have all the dependencies installed, then the pylint inference will be less intense. I'll try installing everything and see what happens. |
I installed as much as I could, but some things were not available - for example, Traits 4.3.0 is no longer available for download. I think in general though that the problem is simply 'too much code'. Pylint builds up a map of all code in the project but also follows inference chains for libraries used, so there will be so much going on. This is basically a limitation of pylint/astroid rather than a bug in prospector. I'm not sure exactly what could be done either, without severe restructuring to avoid recursing when inferring types. The only solution I have would be to run prospector several times on different parts of the code. |
Makes sense to me. BTW, we are trying to get rid of Traits as a dependency. Good to know you can't even download it any more! |
(i have a love/hate relationship with traits too) the reason it doesn't find it is because enthought does a very poor job of publishing it, this is what pip sees: https://pypi.python.org/simple/traits/ -- as you see, 4.3.0 just redirects to a website where no download is found, you can probably safely upgrade to latest traits. |
I'll close this as there's not much I can do to fix it and #93 covers what can be fixed. |
That's fine. Thanks for the help ! On Jan 10, 2015, at 11:16 PM, Carl Crowder <notifications@github.commailto:notifications@github.com> I'll close this as there's not much I can do to fix it and #93#93 covers what can be fixed. — Herb Schilling |
Prospector already solves the issues in prospector-dev/prospector#73
Prospector solved the issues in prospector-dev/prospector#73
For a very large code base ( https://github.com/OpenMDAO/OpenMDAO-Framework ) , I get this in the output
.:
L-:- None: pylint - failure
Tool pylint failed to run (exception was raised)
.:
L-:- None: vulture - failure
Tool vulture failed to run (exception was raised)
There are no errors given by either tool as a result.
I tried using pylint and vulture with some smaller codes and it worked fine.
Great tool though!!!
The text was updated successfully, but these errors were encountered: