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

Утилитки обычно обходятся стандартными зависимостями из дистрибутива питона, но попадаются и такие, кому нужны внешние зависимости. Их, само собой, предлагается "установить в экосистему" через pip install. Идея делать глобальную установку чего-либо для заведомо одноразового софта вызывает стойкое отвращение. В таких случаях разумно обойтись складыванием всего необходимого в каталог самой утилиты (кучей или в подкаталоги).

Полез гуглить на эту тему, ожидая найти относительно несложные правила именования/размещения, но внезапно оказалось, что наиболее правильным для таких случаев считается создание virtual environment, представляющего собой полную копию дистрибутива питоновского интерпретатора.

У них действительно все настолько убого, и питон категорически не умеет искать зависимости "поблизости" от основного кода, запрашивающего импорт? Или все-таки достаточно несложных действий, вроде распаковки зависимостей в подкаталоги, с возможным их указанием в каком-нибудь файле конфигурации, а virtual environment предлагается в первую очередь самым тупым юзерам?

ЕМ>питон категорически не умеет искать зависимости "поблизости" от основного кода, запрашивающего импорт?

Обитатели RSDN категорически не умеют гуглить?

https://www.reddit.com/r/Python/comments/2w20v4/can_i_install_and_use_dependencies_on_a_local/

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У них действительно все настолько убого, и питон категорически не умеет искать зависимости "поблизости" от основного кода, запрашивающего импорт? Или все-таки достаточно несложных действий, вроде распаковки зависимостей в подкаталоги, с возможным их указанием в каком-нибудь файле конфигурации, а virtual environment предлагается в первую очередь самым тупым юзерам?

Чем дальше, тем больше софта на Питоне требует установки докера, в котором у них собрано так, как у разработчика. Так что виртуальные окружения самого Питона или Анаконды — это даже благо на общем фоне.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У них действительно все настолько убого, и питон категорически не умеет искать зависимости "поблизости" от основного кода, запрашивающего импорт? Или все-таки достаточно несложных действий, вроде распаковки зависимостей в подкаталоги, с возможным их указанием в каком-нибудь файле конфигурации, а virtual environment предлагается в первую очередь самым тупым юзерам?

Лень по пунктам отвечать, поэтому отвечу в целом:

В питоне сделано как раз очень удобно. Ты можешь установить сколько хочешь версий питонов и версий библиотек для них. Они не будут влиять друг на друга, и вообще не будут влиять глобально на твою систему (в отличие от .net)

Для этого для проекта создают "виртуальное окружение". Виртуальное окружение — это обычная папка, которая может лежать где угодно, например, в папке твоего скрипта. Это не что-то страшное как .net, которая устанавливает повсюду в системе. Это просто папка, которую ты можешь использовать для проекта, а потому просто удалить. Внутри окружения у тебя установлен питон и библиотеки. Запустил питон из папки окружения — он автоматически подхватил все библиотеки, установленные в окружении. Т.е. ищет библиотеки поблизости, как ты и хочешь

Выполняется создание окружения двумя командами — "создать окружение для питона версии такой-то (или дефолтной)" и "установить все нужные библиотеки — pip install"

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

Здравствуйте, Буравчик, Вы писали:

Б>В питоне сделано как раз очень удобно. Ты можешь установить сколько хочешь версий питонов и версий библиотек для них. Они не будут влиять друг на друга, и вообще не будут влиять глобально на твою систему (в отличие от .net)

Я уже когда-то писал простыню, что этот подход не очень удобен.
На том же С++ к обратной совместимости относятся достаточно скурпулёзно. Поэтому подход, когда большой проект из разносторонних библиотек можно собрать одним компилятором является вполне рабочим: ошибок мало, компилятор бОльшую часть из них находит сам, в некоторых случаях ветки кода с разными библиотеками разделяются #ifdef, а где-то ещё на этапе CMake.
Да, плюсовое окружение сделать сложно, трудоёмко, всё надо будет пересобирать. Но можно.

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

Банально, для плюсового проекта нет проблемы перейти на любую версию CUDA/cuDNN/TensorRT. В Питоновском приложении окажется, что PyTorch работает с фиксированным их набором. Другие библиотеки работают с фиксированным подмножеством версий PyTorch. А третьи библиотеки уже с другим подмножеством. И так со всеми зависимостями. В итоге мы получим ад со сборкой не легче, а то и намного хуже плюсового.
Вот тут и всплывает любовь к Докерам, окружениям и разного рода избыточным API там, где достаточно было бы просто вызвать локальную функцию

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Полез гуглить на эту тему, ожидая найти относительно несложные правила именования/размещения, но внезапно оказалось, что наиболее правильным для таких случаев считается создание virtual environment, представляющего собой полную копию дистрибутива питоновского интерпретатора.

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

Здравствуйте, σ, Вы писали:

σ>Обитатели RSDN категорически не умеют гуглить?
σ>https://www.reddit.com/r/Python/comments/2w20v4/can_i_install_and_use_dependencies_on_a_local/

Это я видел, но интерпретатор категорически не хотел импортировать модули из пути, который я определял в PYTHONPATH, поэтому и подумал, что нужно еще какое-то колдунство. А когда догадался вставить в скрипт вывод sys.path, оказалось, что значение PYTHONPATH туда не попадает (3.8.8 и 3.8.10 под винду). Когда вставил в скрипт sys.path.append — стало импортировать.

Почему интерпретатор может не добавлять значение PYTHONPATH в sys.path? Везде пишут, что достаточно лишь определить, больше ничего делать не нужно.

Здравствуйте, Буравчик, Вы писали:

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

Это удобно, согласен.

Б>Внутри окружения у тебя установлен питон и библиотеки.

А вот это неудобно, и технически неправильно. На кой черт копировать и интерпретатор, и его стандартные библиотеки? Они должны лежать на своих местах, а алгоритмы поиска зависимостей — настраиваться на разные пути. В описаниях я вижу вполне разумные и логичные правила, но вот PYTHONPATH у меня почему-то упорно не попадает в sys.path.

Б>Запустил питон из папки окружения — он автоматически подхватил все библиотеки, установленные в окружении. Т.е. ищет библиотеки поблизости, как ты и хочешь

Поблизости от самого интерпретатора лежат его собственные библиотеки, а зависимости выполняемого скрипта логично искать поблизости от него, если не указано иное.

Б>Выполняется создание окружения двумя командами — "создать окружение для питона версии такой-то (или дефолтной)" и "установить все нужные библиотеки — pip install"

Именно эти команды мне и не нравятся. Они сделаны для управления той самой экосистемой, которая лично мне на хер не упала.

Здравствуйте, night beast, Вы писали:

NB>при создании venv ты можешь сказать использовать имеющиеся в системы библиотеки а не делать их копию.

Я подозреваю даже, что и копию интерпретатора можно не делать. Но достало, честно говоря, раскапывать все это в их документации по чайной ложке в разных местах. Грамотная документация выглядит либо как "для этого необходимо создать каталоги ..., поместить в них файлы ..., установить переменные окружения ..., для автоматизации всего этого достаточно выполнить команду ...", либо как "для автоматической настройки выполните команду, ручная настройка описана здесь". А у этих — ни то, ни се: по умолчанию предлагаются встроенные команды, но описание того, как должна в итоге выглядеть конфигурация, надо разыскивать самому и в разных местах.

ЕМ>Почему интерпретатор может не добавлять значение PYTHONPATH в sys.path? Везде пишут, что достаточно лишь определить, больше ничего делать не нужно.

Какие-то вендопроблемы

$ PYTHONPATH=/moon python -c 'import sys; print(sys.path)'
['', '/moon', ...

Здравствуйте, σ, Вы писали:

σ>Какие-то вендопроблемы

Венда ни причем, проблемы у питона. У меня хватает софта, зависящего от переменных среды — у него проблем нет.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Венда ни причем, проблемы у питона. У меня хватает софта, зависящего от переменных среды — у него проблем нет.
Скорее всего руки кривые ты что-то делаешь не так или с установкой питона или пакетов.
Мой совет по уменьшению траха особенно на винде — https://docs.anaconda.com/miniconda/

(dev) C:\Users\novitk>set PYTHONPATH=c:\temp
(dev) C:\Users\novitk>python -c "import sys; print(sys.path)"
['', 'c:\\temp', ...

Здравствуйте, Nuzhny, Вы писали:

N>В Питоне так не работает. Надо делать окружения со своими версиями библиотек. Если не хочешь тр..ться с приведением всех библиотек и всех их зависимостей к одним версиям, то большое приложение написать не получится, оно будет состоять из пачки взаимодействующих процессов из своих окружений, а то и версий Питона.
N>Банально, для плюсового проекта нет проблемы перейти на любую версию CUDA/cuDNN/TensorRT. В Питоновском приложении окажется, что PyTorch работает с фиксированным их набором. Другие библиотеки работают с фиксированным подмножеством версий PyTorch. А третьи библиотеки уже с другим подмножеством. И так со всеми зависимостями. В итоге мы получим ад со сборкой не легче, а то и намного хуже плюсового.
ИМХО ты преувеличиваешь как проблему в py, так и любовь плюсовиков к обратной совместимости. В моей практике собрать работающее согласованное окружение из современных версий в py просто, а с conda очень просто. Сильно проще чем на плюсах с их зоопарком в build tools. Проблема которую ты описываешь возникает только если к древнему говну мамонта внезапно захотелось приварить что-то ново-молодежное. Во-первых, редко. Во-вторых, сам себе злой буратин, так как ленился апгрейдить.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А вот это неудобно, и технически неправильно. На кой черт копировать и интерпретатор, и его стандартные библиотеки? Они должны лежать на своих местах, а алгоритмы поиска зависимостей — настраиваться на разные пути. В описаниях я вижу вполне разумные и логичные правила, но вот PYTHONPATH у меня почему-то упорно не попадает в sys.path.

Если не тебе не нужен отдельный питон, то да, можешь использовать системный, просто указывая PYTHONPATH (как ты и пытаешься сделать).

Почему не работает — какая-то проблема у тебя на компе. Может запускаешь не бинарь питона, а какой-то скрипт. Может ошибся в команде. Может питон установлен криво. Куча вариантов может быть

ЕМ>Поблизости от самого интерпретатора лежат его собственные библиотеки, а зависимости выполняемого скрипта логично искать поблизости от него, если не указано иное.

Питон так и делает. Стандартные пути для поиска модулей:
— папка установки питона (виртуальное окружение, возможно глобальное) — ищем глобальные либы
— текущая папка откуда запущен питон в данный момент — ищем локальные либы скрипта
— PYTHONPATH — ищем вспомогательные либы

ЕМ>Именно эти команды мне и не нравятся. Они сделаны для управления той самой экосистемой, которая лично мне на хер не упала.

Если тебе достаточно глобального питона (установленного в системе), и ты готов его "загрязнить" библиотеками какого-то конкретного проекта, то нет проблем. Просто доустанови библиотеки, необходимые для твоего проекта, и запусти питон из папки скрипта

Здравствуйте, novitk, Вы писали:

N>Скорее всего руки кривые ты что-то делаешь не так или с установкой питона или пакетов.

Если б я был обычным юзером, то еще мог бы заподозрить себя в "делании не так". Но питон я вообще никак не устанавливаю — просто распаковываю его дистрибутив в отдельный каталог, и он там нормально работает, я ж не впервые использую питоновские скрипты. И os.environ.get ("pythonpath") возвращает текущее значение PYTHONPATH, только вот в sys.path оно почему-то не добавляется. Это однозначный косяк модуля sys, без вариантов.

N>Мой совет по уменьшению траха особенно на винде — https://docs.anaconda.com/miniconda/

То есть, в дополнение к траху с питоном, предлагаете мне трахаться еще и анакондой?

Здравствуйте, Буравчик, Вы писали:

Б>какая-то проблема у тебя на компе.

Она поддается диагностике?

Б>Может запускаешь не бинарь питона, а какой-то скрипт.

Запускаю python.exe.

Б>Может ошибся в команде.

В какой?

Б>Может питон установлен криво.

Как именно он может быть "криво установлен"? Какая, по-Вашему, магия происходит во время "прямой установки", чтобы результат отличался от "кривой установки" именно так — все скрипты выполняются правильно, os.environ.get ("pythonpath") возвращает значение PYTHONPATH, но в sys.path это значение не добавляется?

Б>- папка установки питона (виртуальное окружение, возможно глобальное) — ищем глобальные либы
Б>- текущая папка откуда запущен питон в данный момент — ищем локальные либы скрипта
Б>- PYTHONPATH — ищем вспомогательные либы

По факту оно работает не так. Каталоги импортируемых пакетов лежат в текущем каталоге (где и основной скрипт), в каждой из них лежат __init__.py, но import не видит их без добавления текущего каталога в sys.path.

Б>Если тебе достаточно глобального питона (установленного в системе), и ты готов его "загрязнить" библиотеками какого-то конкретного проекта

Как раз не готов. Если и буду в глобальный комплект что-то добавлять, то лишь популярные модули/пакеты общего пользования. То, что нужно лишь конкретным скриптам — или в их собственные каталоги, или тоже в общие, но вторичные, разделяемые между совместимыми версиями интерпретатора.

N>>Мой совет по уменьшению траха особенно на винде — https://docs.anaconda.com/miniconda/

ЕМ>То есть, в дополнение к траху с питоном, предлагаете мне трахаться еще и анакондой?

По сравнению с трахом с вендой это мелочи

Здравствуйте, σ, Вы писали:

σ>По сравнению с трахом с вендой

Э-э-э... В чем именно заключается "трах с вендой"? Я чего-то не знаю о своей венде?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если б я был обычным юзером, то еще мог бы заподозрить себя в "делании не так". Но питон я вообще никак не устанавливаю — просто распаковываю его дистрибутив в отдельный каталог, и он там нормально работает, я ж не впервые использую питоновские скрипты. И os.environ.get ("pythonpath") возвращает текущее значение PYTHONPATH, только вот в sys.path оно почему-то не добавляется. Это однозначный косяк модуля sys, без вариантов.
Тебе показали, что PYTHONPATH появляется в sys.path на винде. У тебя не появляется. Очевидно у тебя что-то работает не так. У чего и кого тут однозначный косяк

N>>Мой совет по уменьшению траха особенно на винде — https://docs.anaconda.com/miniconda/
ЕМ>То есть, в дополнение к траху с питоном, предлагаете мне трахаться еще и анакондой?
Тебе дали совет, как правильно на винде поставить любую версию питона с любым набором библиотек в 10 минут без build tools и прочих шлюх. Ты вместо этого хочешь трахатся со своим неправильно работающим, но зато "просто распакованным" дистрибутивом? Да, на здоровье! Мы то как тебе в этом можем помочь?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Она поддается диагностике?

Да. Сделай скрипт вида

import os
import sys

print('os.getcwd:', os.getcwd())
print('sys.path:', sys.path)
print('path env:', os.environ.get('PYTHONPATH'))
print('env:', os.environ)

И запускай питон — с переменными окружения и без. Сравнивай результаты.
Посмотри, попадает ли в пути текущая папка, pythonpath и т.п.

ЕМ>Как именно он может быть "криво установлен"? Какая, по-Вашему, магия происходит во время "прямой установки", чтобы результат отличался от "кривой установки" именно так — все скрипты выполняются правильно, os.environ.get ("pythonpath") возвращает значение PYTHONPATH, но в sys.path это значение не добавляется?

почему pythonpath маленькими буквами?

ЕМ>По факту оно работает не так. Каталоги импортируемых пакетов лежат в текущем каталоге (где и основной скрипт), в каждой из них лежат __init__.py, но import не видит их без добавления текущего каталога в sys.path.

Если в sys.path есть папка '', значит интерпретатор все увидел
init.py — не нужен для третьего питона