Sorry if this has already been asked, but I am wondering how I can get linting to work in VS Code in a consistent way with the pants cli. In my pants.toml file, I have added some python specific linting backends like this

[GLOBAL]
pants_version = "2.9.0"
backend_packages = [
    "pants.backend.python.lint.black",
    "pants.backend.python.lint.flake8"
]

How do I correctly set up my path such that VS code is able to find the executable for

black

and

flake8

to allow it to invoke those linters/formatters? I am creating a virtual environment the pre-export way but I don't see black or flake8 binaries in the bin directory for that venv

Hi, welcome! Indeed, Pants does not yet(?) export tool lockfiles for tools like Black and Flake8. Relates to this thread https://pantsbuild.slack.com/archives/C0D7TNJHL/p1644397600652729 We're definitely eager to here about what you're looking for and to figure out how to make this more user-friendly

Thanks for responding! I tried to read through that thread and the linked GitHub issue. I see what you mean that it could be weird for pants to install those tools into a user's virtualI environment automatically. I think in most cases, if the user has enabled the backend in pants, they want to use the tool so maybe in practice it is not too much of a concern. I think allowing users to specify that they want black as a dependency and then allowing pants to use my preferred version of that dependency when I run

./pants lint ::

would solve this for me. (I think that is what the GitHub issue is advocating for, correct me if I am misunderstanding it). I am coming from a JS background. In that world it is fairly common for folks to include an executable tool such as a formatter or linter as a dev dependency to allow the build system to use it. Ultimately it would be cool if I could click "format document" or "run linting" in VS Code, and know that it would run in the same way that

./pants fmt

or

./pants lint

would. For now, I am just running

pip install $tool

in that virtual env and hoping I get a compatible version with the same config.

yeah there are a couple of different angles we could take, not sure which we should pursue: 1. Let you reuse the same

python_requirement

for both your own normal code and the tool lockfile, like

[black].version

and

[black].extra_requirements

. This would make it more feasible to include Black in the result of

./pants export ::

2. Export dedicated virtualenvs per tool, which would let you point your IDE to use the Black binary from that tool's venv, for example. Pretty feasible for us to implement 3. Mix in the tool venvs with your user requirements venv. The benefit is you have only one venv w/ everything in it, but the downside is that it's likely to cause issues trying to mix them. Not very feasible fwict 4. First-class VSCode support, which we're working on via BSP https://github.com/pantsbuild/pants/issues/13260. I wonder if that will allow us to wire into VSCode's fmt support automatically, not sure cc @nutritious-hair-72580

I think #2 would be a useful first step assuming it would be part of

./pants export ::

(or at least optionally). Looks like both VSCode and PyCharm support custom paths for black, flake8, etc. I’d put in the docs the VSCode

settings.json

example config - e.g.

{
  "python.linting.flake8Path": "./dist/tools(?)/..."
}

I’m not sure if/how the equivalent is done programmatically in PyCharm, but it’d be pretty easy to infer from VSCode settings as a start.

I know very little about vscode, but ideally it would run linters by invoking

./pants lint

itself rather than trying to replicate what

./pants lint

does.

I don’t think

./pants lint

will give you hint/problems in the GUI when things are wrong. The VSCode extension (I’m not sure if it’s in the one python extension or a separate flake8 one) handles that.

re:

I know very little about vscode, but ideally it would run linters by invoking 

./pants lint

 itself rather than trying to replicate what 

./pants lint

 does.

Is that not easy to set up?

AFAIK it is handled by the python extension https://marketplace.visualstudio.com/items?itemName=ms-python.python which is maintained by Microsoft and touted as the "best" option for getting python development set up in VS Code. That extension has a list of linters it knows how to work with https://code.visualstudio.com/docs/python/linting#_specific-linters which enables the hints in the UI. As @nutritious-hair-72580 mentioned those linters can be configured to use a custom path

A custom path is generally unnecessary as the Python extension resolves the path to the linter based on the Python interpreter being used (see Environments). To use a different version of a linter, specify its path in the appropriate custom path setting. For example, if your selected interpreter is a virtual environment but you want to use a linter that's installed in a global environment, then set the appropriate path setting to point to the global environment's linter.

So I think option #2, giving the tool its own virtual environment would be fine for me

Thanks Ryan!! If you ever want to dabble in Rust, we're happy to add you to reviews or help with any changes: https://www.pantsbuild.org/v2.10/docs/contributions-rust. A couple of us (including me) learned Rust via this project Blog post coming soonish going into more detail about how specifically we use Rust + Python. https://blog.pantsbuild.org/fast-incremental-builds-speculation-cancellation/ is a neat blog too

I would love to be included on some reviews! I have a decent understanding of the borrow checker and basic rust, but I am definitely lacking real world project experience, so seeing how you folks use it would be very eye opening.

Cool! If you have interest in code changes, https://github.com/pantsbuild/pants/issues/12863 and https://github.com/pantsbuild/pants/issues/13608 could be interesting. Happy to add more thoughts if you're interested

I might need some more info about https://github.com/pantsbuild/pants/issues/12863 but removing usages of

.unwrap()

seems like something I might be able to do without much help! I will clone the project and see what things look like

I think the lesson here is that I need to switch from PyCharm to VSCode for a bit, so I know more about it...

Ha I am thinking the opposite, my whole team uses PyCharm 🙂

I recently switched, only because the Python extension was using 100% CPU and I couldn’t figure out a fix. Pycharm seems a lot more helpful, especially with refactoring, but there are bits of VSCode I miss.