init-hook=import inspect; sys.path.append(os.path.dirname(inspect.stack()[2][0].f_locals["linter"].config_file)) However, since this essentially couples us to the internals of pylint, it would be nice to have something a little less invasive. I prepared a
Hello, We are in the early phases of rolling out pylint to our Python application. We have a particularly strange setup where we use __path__ in a number of "virtual packages" in order to set the correct location of the real package. Activating astroid's behavior which scans sys.path (the from pkgutil import extend_path trick) in combination with manipulating sys.path in an init-hook works great and allows pylint to see the package the same way the interpreter does. However, figuring out the correct path to insert onto sys.path is unfortunately not trivial, since we support running pylint as part of our pre-commit review tool, which runs it in a different directory but passes --rcfile on the command-line. In order to get the correct directory, we need to have the path of the current rcfile (be it one that came from config.find_pylintrc or one that came from --rcfile). Unfortunately, it seems that config.PYLINTRC does not get updated to include the path of the file if --rcfile is given. Our current solution to this problem is to use inspect within the init-hook to step back up to the frame of Run and look at the config_file member of the linter: patch to pylint/lint.py that would set config.PYLINTRC in cb_set_rcfile. That allows the init-hook above to be replaced by:
init-hook=sys.path.append(os.path.dirname(config.PYLINTRC)) And preserve the same behavior.
My question is, would this be a change that the project is interested in? I didn't just want to send a pull request out of the blue, since the actual change is trivial. Is there some better way to accomplish what I am trying to do? Thanks for your consideration, tjs -- Tim Stumbaugh Operations Hudson River Trading