mason.nvim
mason.nvim copied to clipboard
Flake8 plugins not working
Problem description
I use flake8 as my linter with a bunch of plugins to add extra linting. If I open a terminal in neovim and ask which flake8 I get
/home/guillem/.local/share/nvim/mason/bin/flake8
confirming that I'm using the flake8 program installed by mason when inside neovim.
I also have a python environment activated prior to opening neovim which I need to do so that the LSP works.
Mason puts itself before the flake8 installed on the venv and so all the flake8 plugins that I had there are not longer available and provide no lints. I can confirm this by running flake8 outside neovim, this uses the binary from the venv, which shows all the expected lints. However running flake8 from a terminal window inside nvim only shows the small amount of lints provided by flake8 by default. This are the same lints as shown on the diagnostics.
Why do you think this is an issue with mason.nvim?
Mason overrides the flake8 provided by the venv making the plugins unavailable. This wouldn't be so problematic if Mason provided a way to add flake8 plugins. I have installed the plugins using the pip within /home/guillem/.local/share/nvim/mason/bin but this didn't fix the situation.
Neovim version (>= 0.7)
NVIM v0.7.2 Build type: RelWithDebInfo LuaJIT 2.1.0-beta3
Operating system/version
Linux pop-os 5.11.0
I've manually reviewed the Nvim LPS client log (:MasonLog) to find potential errors
- [X] Yes
I've recently downloaded the latest plugin version of mason.nvim
- [X] Yes
Affected packages
mason.nvim
Steps to reproduce
- Create a Python venv and install flake8 plus some plugins e.g. pep8-naming and flake8-variables-names
- Activate the venv prior to opening neovim
- Install and configure flake8 with Mason, plus an LSP.
- Close neovim and open it while editing a python file.
- Attempt to trigger a lint on one of the plugins e.g.
x=2-> single character variable names are not allowed
The above steps may require a .flake8 file to actually "activate" the relevant lints.
Actual behavior
Lints from flake8 don't show when using Mason.
Expected behavior
Lints from flake8 plugins on the venv should show when using Mason or Mason should allow some way to add flake8 plugins
Healthcheck
mason: require("mason.health").check()
========================================================================
## mason.nvim report
- OK: neovim version >= 0.7.0
- WARNING: **Go**: not available
- OK: **cargo**: `cargo 1.62.1 (a748cf5a3 2022-06-08)`
- WARNING: **luarocks**: not available
- OK: **Ruby**: `ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux-gnu]`
- OK: **RubyGem**: `3.2.5`
- WARNING: **Composer**: not available
- WARNING: **PHP**: not available
- OK: **npm**: `7.5.2`
- ERROR: **node**: unsupported version `v12.21.0`. Node version must be >= 14
- OK: **python3**: `Python 3.9.5`
- OK: **pip3**: `pip 22.2 from /home/guillem/.local/lib/python3.9/site-packages/pip (python 3.9)`
- OK: **javac**: `javac 11.0.11`
- OK: **java**: `openjdk version "11.0.11" 2021-04-20`
- OK: **julia**: `julia version 1.7.2`
- OK: **wget**: `GNU Wget 1.21 built on linux-gnu.`
- OK: **curl**: `curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1j zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh/0.9.5/openssl/zlib nghttp2/1.43.0 librtmp/2.3`
- OK: **gzip**: `gzip 1.10`
- OK: **tar**: `tar (GNU tar) 1.34`
- OK: **bash**: `GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)`
- OK: **sh**: `Ok`
- OK: **python3_host_prog**: `Python 3.9.7`
- OK: GitHub API rate limit. Used: 0. Remaining: 60. Limit: 60. Reset: Thu 28 Jul 2022 02:52:50 PM BST.
Screenshots or recordings
No response
I finaly figured out that I could go into the nvim/packages/flake8 folder and activate the venv there and then install the flake8 plugins. This did the trick:
- cd to
~/.local/share/nvim/mason/packages/flake8 - activate the venv:
source venv/bin/activate pip install some-flake8-plugin
Is there some API to add additional packages to the venv associated with one of the installed python tools?
I can confirm that the same goes for pylint and its plugins, e.g. pylint-pytest.
I think that ideally, Mason should not place its bin directory before everything else in the PATH. It would be nice to have some tools installed by default by Mason for quick prototyping and not see complaints from null-ls about missing binaries, but at the same time have those tools overridden with local binaries when working on actual projects, e.g. at work, when we may need specific pinned versions of those tools as well as some plugins for them.
That said, I am unsure about the possible negative consequences of that approach so adding the possibility to install such extensions, as @GCBallesteros suggested, seems like a nice idea.
Hey! So there's currently no nice way to add additional dependencies to an installed Mason package, you'll have to drop into the installation location and manually do so (should be rather easy as these tend to just be pip/npm/etc. packages that need to be installed adjacent to the main package).
I believe pylsp was the very first server with plugins, it was solved by introducing a :PylspInstall command. That particular solution was just a fast way to work around it, but now when the number of packages has significantly increased I'd like to do it differently. One idea I've had is to simply introduce these as "sub-packages" that would be regular Mason packages under the hood. Automatic dependency resolution could potentially also be included, where for example pylsp is automatically installed when installing pyls-flake8.
I'll go ahead and close this issue for #392, let me know if you disagree
I'll go ahead and close this issue for #392, let me know if you disagree
I welcome the changes in #392, but I would disagree it solves the problem. However, there are also is another different problem to solve in this context:
A lot of the time (especially in work environments -- or open source!) we work with different projects who use different versions of tools like flake8 and different flake8 extensions. So it would definitely be preferred to use the version of the tool which is native to the project, as per the project requirements or policies, instead of prepending the flake8 binary from mason in the PATH. So it would be preferrable to use the virtual env versions of tools in favor of any global installed ones. (As a side note that would be kind of consistent with the way pip works already)
If you see any problems with this approach or you have ideas how it can. be integrated to mason, I would be interested to discuss.