1

I have several Python solutions created with VS Community 2013 with PTVS 2.1. PyLint works fine in all these projects.

I recently installed VS Community 2015 with PTVS 2.2. I can open and run these VS 2013 projects in VS 2015 with no problems. However, when I run PyLint in VS 2015, I get errors like this (from VS Output window):

No config file found, using default configuration
************* Module spamreport.py
spamreport.py(1,0): warning F0001: No module named spamreport.py [F:fatal]
************* Module spamscan.py
spamscan.py(1,0): warning F0001: No module named spamscan.py [F:fatal]
************* Module spam_logger.py
spam_logger.py(1,0): warning F0001: No module named spam_logger.py [F:fatal]
************* Module utils.py
utils.py(1,0): warning F0001: No module named py in C:\Python34\lib\site-packages\pylint\checkers/['utils', 'py'] [F:fatal]

I can run PyLint from a console no problem.

D:\Users\Clayton\Code\Python\disqus>pylint spamscan.py


Report
======
131 statements analysed.

...

However, if I run PyLint from the wrong directory, I get a similar error:

D:\Users\Clayton\Code\Python>pylint spamscan.py
************* Module spamscan.py
F:  1, 0: No module named spamscan.py (fatal)

This seems to suggest VS 2015 is not using the correct working directory. I've checked the Project Properties and the Project Folder and Project Home entries are correct. I've tried rebuilding the solution from scratch as a VS 2015 solution, but the results are the same.

VS Community 2015 and PTVS 2.2 were both released just a few days ago. Anyone else encountering this issue? Any ideas how to fix this?

  • I've had other minor issues in general installing 2015 Pro. Installing from an iso didn't seem to include everything (not all shortcuts were installed, modules missing, etc.). Did it appear to install cleanly for you? – Jeff Mercado Jul 26 '15 at 04:48
  • The only installation errors reported dealt with Azure components, which I could care less about. Other than the PyLint issue, the install seems to work normally. –  Jul 26 '15 at 12:24

1 Answers1

1

I think you might be running into this change. Basically, it used to use the working directory in 2.1, but now it just uses the project file directory (for the sake of uniformity, because that is also what Intellisense uses as root).

Note that you can adjust most aspects of how Pylint is invoked by editing the .targets. Have a look at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Python Tools\Microsoft.PythonTools.targets (adjusted as needed for your system), and search for "Pylint" inside. You'll see how the directory is specified.

I think it would be a good idea to change that in the next release such that it uses its own MSBuild property, something like $(PylintWorkingDirectory), which is set to $(MSBuildProjectDirectory) by default, but only if you don't explicitly set it in your project file. That way you could override it to be whatever you want without mucking around with global .targets. Feel free to file this on GitHub.

Pavel Minaev
  • 99,783
  • 25
  • 219
  • 289
  • Thanks Pavel, that appears to be the issue. Using $(PylintWorkingDirectory) corrects the problem. VS 2013 PTVS 2.1 used $(WorkingDirectory), which also works in VS 2015 PTVS 2.2. Would one be a better solution than the other long term? Filed as Issue 648. –  Jul 26 '15 at 12:48
  • This was originally changed because of a user-reported bug complaining about `$(WorkingDirectory)` :) The problem is that there is no clear choice here - on one hand, the layout of your package (and hence location of relative modules) is really supposed to be relative to project root, and that's what Intellisense picks. But if you specify working directory, then that's where the stuff is run from, and runtime behavior may be different. I think the best we can do is let you customize this, and probably stick to current behavior by default until we get more feedback. – Pavel Minaev Jul 26 '15 at 17:07
  • Oh, by the way, I've just realized that you might also be able to solve this by adding your working directory to Search Paths of the project - I think we pass these on to Pylint (if we don't, file this as a bug as well). – Pavel Minaev Jul 26 '15 at 17:08
  • One of the first things I tried (but neglected to mention) was adding the working directory to Search Paths. Same problem with PyLint. –  Jul 26 '15 at 17:58