We run pylint two ways:

So while it's certainly possible to use environment variables to solve this problem, I think that would be more complicated (given the two different cases) and somewhat difficult to express as an init-hook.

Here's another proposal: would it be amenable to move the function that executes the init-hook to be a method on the linter class, instead of just a pure function in the module? That way, the init-hook could have closer access to the linter (via the "self" name, presumably) and therefore the pylintrc file?

Of course, if you'd prefer not to support this workflow, I completely understand, and our workaround is workable (even if it's a bit brittle).
tjs


On 2016-06-02 17:44, Claudiu Popa wrote:
On Thu, May 26, 2016 at 8:57 PM, Tim Stumbaugh <stum@hudson-trading.com> wrote:
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:

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 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

_______________________________________________
code-quality mailing list
code-quality@python.org
https://mail.python.org/mailman/listinfo/code-quality


Hi Tim,

Sorry for the delay in the first place, I totally forgot about answering.

Unfortunately, config.PYLINTRC doesn't sound to be the right
place for this, since it is just a global constant (after computed),
that we use to determine a potential rcfile. I would be happy with
another one that is designed specifically for this purpose, but another
idea that occurs to me would be to just use an environment variable,
e.g PYLINTRC, which is already used by find_pylintrc function. Then
your hook becomes just
--init-hook="sys.path.append(os.path.dirname(os.environ['PYLINTRC']))"
Would this be a solution you could use?


Claudiu

--
Tim Stumbaugh
Operations
Hudson River Trading