Introduction

An unresolved import warning from Pylint inside Visual Studio Code usually means the linter is not running with the same import path that your application uses. The fix is rarely inside the import statement itself; it is usually in the selected interpreter, package installation, or workspace path configuration.

Confirm That VS Code Is Using the Right Interpreter

Pylint runs in a Python environment, so the first question is whether VS Code is pointing at the environment that actually has your dependencies installed. If the editor is using one interpreter and your terminal is using another, import resolution will drift immediately.

python -c "import sys; print(sys.executable)"
python -m pip show pylint

After checking the terminal, make VS Code match it by selecting the same virtual environment. In workspace settings, that often looks like this:

1{
2  "python.defaultInterpreterPath": ".venv/bin/python",
3  "python.envFile": "${workspaceFolder}/.env"
4}

On Windows, the interpreter path will point into .venv\\Scripts\\python.exe instead. The important point is consistency between the editor, the linter, and the shell you use for installation.

Handle src Layouts the Right Way

A very common case is a project that stores packages under src/. Your app may run fine if the test runner or start script adjusts the path, while Pylint still reports unresolved imports because it sees only the workspace root.

One quick fix is to expose src through the environment file:

PYTHONPATH=src

That works, but the more durable approach is to install the package in editable mode so every tool resolves imports the same way.

1[project]
2name = "myapp"
3version = "0.1.0"
4
5[tool.setuptools.packages.find]
6where = ["src"]

python -m pip install -e .
python -m pip install pylint

Editable installs are usually better than path hacks because they make the project importable for tests, scripts, and linters with one consistent setup.

Configure Pylint When the Project Layout Is Unusual

Monorepos, generated code, or shared internal libraries sometimes need extra path configuration. In that case, configure Pylint explicitly instead of adding sys.path mutations to application code.

[tool.pylint.main]
init-hook = "import sys; sys.path.append('src')"

This keeps the workaround in lint configuration, where it belongs. It also avoids shipping path manipulation inside production modules just to satisfy a development tool.

Separate Pylint From Other VS Code Diagnostics

VS Code may show import warnings from different tools at the same time. Pylint, Pylance, and the Python runtime do not all use the same resolution rules. Fixing one does not automatically fix the others.

If the message specifically says Pylint, focus on the linter environment and Pylint configuration. If the message comes from Pylance, you may also need python.analysis.extraPaths. The symptom looks similar, but the source is different.

Common Pitfalls

• Selecting the right interpreter in the terminal but leaving VS Code pointed at a different environment.
• Fixing the import path for execution while forgetting that Pylint runs with its own environment inside the editor.
• Relying on ad hoc sys.path.append calls in application code instead of packaging the project correctly.
• Treating a src layout as a flat script folder and never installing it in editable mode.
• Solving a Pylance diagnostic and assuming the Pylint warning must disappear as well.

Summary

• Start by checking that VS Code and your shell use the same interpreter.
• Prefer editable installs for package-based projects, especially with src layouts.
• Use .env or Pylint config only when you truly need path customization.
• Keep linter-specific fixes in lint settings, not in production code.
• Distinguish Pylint warnings from Pylance warnings before changing settings.