Patch to expose path of rcfile
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
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
We run pylint two ways: * Interactively, in the same location as the .pylintrc file. We don't explicitly pass it to pylint, and the normal routines for finding a .pylintrc file work well here. There won't be an environment variable set here (since it's just running within a user's shell session), but config.PYLINTRC is correct. * Via arcanist's "arc lint" command, which changes the working directory to the incorrect directory (i.e. pylint can't find an rc file it without help), but with --rcfile. Arcanist has a specific configuration setting just for pylint's rc file which we use. 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
On Thu, Jun 2, 2016 at 11:09 PM, Tim Stumbaugh <stum@hudson-trading.com> wrote:
We run pylint two ways:
Interactively, in the same location as the .pylintrc file. We don't explicitly pass it to pylint, and the normal routines for finding a .pylintrc file work well here. There won't be an environment variable set here (since it's just running within a user's shell session), but config.PYLINTRC is correct. Via arcanist's "arc lint" command, which changes the working directory to the incorrect directory (i.e. pylint can't find an rc file it without help), but with --rcfile. Arcanist has a specific configuration setting just for pylint's rc file which we use.
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
Sure, that sounds like a solution that could work, feel free to send a pull request with it. Claudiu
participants (2)
-
Claudiu Popa -
Tim Stumbaugh