As strongly suggested in the docs, I use a `lockfi...
# general
r
As strongly suggested in the docs, I use a
lockfile
for each tool and use the
export
command to allow my editor (VSCode) to use the same version of the tool that Pants uses for workflows. This works great for most of the tools, except for
pylint
. VSCode complaints that it is unable to import 3rd party packages (
pylint(import-error)
). Take note that Pants
lint
command works as expected. I suspect this is because 3rd party packages are installed in
python-default
venv and not in
pylint
tool venv. Anybody has this problem? I know it is not a Pants problem per say, but more an IDE integration issue...
2
s
I’ve also had this problem with
pylint
, but haven’t managed to solve it 😕
😟 1
I also see errors when it tries to load first-party plugins from the repo sources
h
To clarify, the issue is being unable to import the 3rdparty dependencies of your code, or of pylint itself?
Presumably the former?
s
the former - pylint doesn’t see the 3rdparty deps on the PYTHONPATH and flags them as bad imports
h
Yeah, I guess pylint assumes that the 3rdparty dependencies of your code are importable in the same virtualenv it is running in
👍 1
Which is how pylint is used in practice, even though it is not ideal due to potential conflicts between pylint's deps and your deps
So I guess what we need is a way to merge two exported venvs
👍 2
s
there is a flag you can pass to pylint to execute arbitrary code before it loads anything else; I was playing with it awhile back to dynamically modify
sys.path
to include the other exported venvs, but couldn’t get it to work
👍 1
h
Another argument for reconsidering how export works (see https://pantsbuild.slack.com/archives/C046T6T9U/p1658497691368129)
s
https://stackoverflow.com/a/3065082 yeah, the
--init-hook
arg/flag
h
So something like
./pants export --type=virtualenv --lockfiles=python-default,pylint
would create a single venv with both those lockfiles in it (and if a conflict arose it would... I dunno, re-resolve, or let one win arbitrarily)
🤔 1
👀 1
Just guessing at what the CLI would be like, but it sounds like we do need to be able to create a single venv combining multiple lockfiles somehow
that is what external use-cases are going to expect most of the time
because it's how Python be in practice...
s
at least for my use-case, all of this is working around lack of IDE support for Pants. if the LSP/BSP support could be extended to Python I don’t think I’d ever use
export
👍 3
r
pylint doesn’t see the 3rdparty deps on the PYTHONPATH and flags them as bad imports
Hi Benjy, yes, the former...
h
Yeah that is definitely the main use-case for exporting virtualenvs, and LSP/BSP would be the right way to get more seamless IDE support going
👍 1