Start pycheckers.py or checkers from cvs root or from emacs cwd

[JulienPalard]

Currently pycheckers.py is invoked with the checked file dirname as its working directory, so checkers are also started with their files directories as cwd.

Typically if I have tests/test_app.py I would manually run pylint tests/test_app.py but flycheck-pycheckers would run the equivalent of (cd tests; pylint tests/test_app.py).

This is probably bad, first because that's not how users start their linters, so they may see differences between flycheck-pycheckers and their manually started linters.

Typical differences is if their checked files are importing files available at the root the the repository, running pylint tests/test_app.py would work, but cd tests; pylint test_app.py would report an import error.

I think pycheckers should be ran relatively to the emacs cwd (where emacs was initially started) but in some cases and some habits it may be wrong, and using the cvs root may be better, so I'm still unsure on what's best here, maybe this need feedback from users.

[msherry]

First off, thanks for taking the time to write up an issue!

I did actually look at this when working on #2 -- iirc, using the project root as the cwd was just a matter of passing a cwd arg to one of the Popen calls, and munging the output a little bit so that flycheck would parse it correctly. It's probably easy enough to do if there's a need for it.

I'm not yet convinced that there is, though. The import issue you mention sounds like a red herring -- as far as I know, Python imports are either absolute or relative to the file performing the import. If you can produce a minimal example that demonstrates the failure you describe, please share it and I can take a look!

As for running relative to where Emacs was initially started, I'm afraid that's a nonstarter for me. I start up Emacs in a GUI, and leave it running for days or weeks at a time, so the directory for the process is generally useless in determining where to run pycheckers from. A config option to cd to the root of the project may be a solution to the issue you describe, though.

[JulienPalard]

As for running relative to where Emacs was initially started, I'm afraid that's a nonstarter for me. I start up Emacs in a GUI

That's what I though some may legitimately do, so it's a no-go to use emacs working directory, I agree.

And for searching for the vcs root it does not look the perfect idea neither, typically if one still has not typed its git init but already boostraped the project, it will have strange errors that will strangely disapear by running git init, which is strange as completly unrelated.

I see no perfect solution at the moment.

My issue is https://github.com/encode/apistar is creating an app.py at the root of the hiearchy, and uses import app in tests/*.py. I fixed this by moving the content of app.py in a package, and adding a single line from my_package.app import app in app.py, I no longer use their import app but I use my from my_package.app import app in tests, as my_package is installed, it's in the Python path, and therefore found by pylint.

So in one hand it's fixable by doing things properly, but in the other hand newcomers may be bitten by similar contexts, having pylint working from the root, finding include some_file_at_the_root.py but not working when started with a different working directory.

[msherry]

Closing this out as a fix was merged.