Использование VS Code Python extension - Как установить модули Python на постоянное место за пределами виртуальной среды?

Question

Я работаю с Python 3.7 и использую VS Code в качестве своей IDE. У меня установлено расширение Microsoft Python, и я включил pylint для linting и pytest для модульных тестов, устанавливая их в системную папку сценариев python37, без какой-либо виртуальной среды, присутствующей или активной.

На данный моментКажется, все работает. Мой Python37/Scripts путь находится в системе Windows PATH, и там присутствуют основные скрипты / exe pytest и pylint. VS Code может найти и запустить мои тесты, и работает нормально.

Теперь я устанавливаю виртуальную среду для пакета, над которым я работаю, и меняю интерпретатор Python на виртуальную среду с именем .venv.

После этого я устанавливаю все свои зависимости пакета, и все, кажется, работает, но VS Code открывает окна, которые сообщают мне, что pylint и pytest не установлены.

Если я нажимаю yes для установки он, кажется, устанавливает их с текущим исполняемым файлом Python по умолчанию (в данном случае это Python 3.7 из моей виртуальной среды .venv), но использует опцию --user для установки его в папку Python\Python37\Scripts пользователей (в папке \users\user\appdata\roaming), даже если она уже существует в папке моей системы python37\Scripts, которая находится по пути (установленному без активированной виртуальной среды).

Но даже после установки расширения установите ихтак, как он хочет, я все еще не могу обнаружить свои тесты автоматически, и когда я пытаюсь настроить тесты, он пытается установить в каталог пользователя, носнова.

-

Итак, я думаю, все это, чтобы спросить - это дефект в VS Code?

Есть ли способ установить стандартные инструменты Python? хотите использовать в постоянном месте, что VS Code всегда найдет, или мне нужно переустанавливать каждый инструмент (например, pylint и pytest) в каждую виртуальную среду, которую я настраиваю?

Если я устанавливаю их вручнуюпакеты в виртуальную среду, похоже, все работает. Является ли единственный вариант их установки (и всех других инструментов, которые я планирую использовать глобально) в каждую виртуальную среду?

Answer 1

Решение (но пересмотрите это, см. Ниже)

Я нашел решение для pylint, (хотя это немного глупо).

Внутри глобальногоНастройки кода VS, для PyLint , найдите параметры кода VS для pylintpath, а затем найдите элемент, указанный ниже, и введите в него путь к вашей пользовательской или системной установке pylint. В Windows это должно быть в формате, показанном ниже, с двойной обратной косой чертой для каждого разделителя пути:

Обратите внимание, что вы также можете ввести абсолютный путьдля pylint только для данной рабочей области или папки, выбрав соответствующую вкладку в настройках.

Для pytest доступна аналогичная настройка, которая, похоже, работает аналогичным образом. Я получаю некоторые «глюки» с обнаружением и запуском pytest (кажется, что каждый тест запускается дважды), но, похоже, он работает.

---

Комментарии от Бретта - переосмыслите эту стратегию

Основываясь на комментариях Бретта Кэннона, я перейду к простой установке пакетов dev в каждой виртуальной среде. Похоже, что это лучшая практика от долгосрочных разработчиков.

Это имеет смысл, когда я считаю, что стандартные инструменты, которые я мог бы предпочесть, могли бы меняться от пакета к пакету, такие как публичные проекты, которые используют разные платформы модульного тестирования,или разные линтеры - потому что все разработчики в этом проекте должны использовать одни и те же инструменты, чтобы избежать коллизий инструментов (то есть думать о простых различиях, таких как интервалы или отступы, когда разные линтеры жалуются по-разному).

Решение для установкиинструменты dev для каждой виртуальной среды

Одним из решений для этого является создание файла requirements-dev.txt со всеми используемыми пакетами инструментов dev, которые можно установить с помощью python -m pip install -r requirements-dev.txt.

Thisпредоставляет способ иметь отдельный список инструментов разработки, которые требуются для работы над проектом, который является распространяемым, но отделен от требований стандартной установки пользователя.

Он также предлагает, чтобы вы могли последовательно подключаться. файлы требований цепочки. Например, первой строкой requirements-dev.txt может быть -r requirements.txt, которая установит все из файла нормальных требований, а затем все остальные требования к разработке после этой первой строки. Это установит как обычные, так и dev-зависимости одной командой.