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

Утилитки обычно обходятся стандартными зависимостями из дистрибутива питона, но попадаются и такие, кому нужны внешние зависимости. Их, само собой, предлагается "установить в экосистему" через 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 — не нужен для третьего питона

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

N>Тебе показали, что PYTHONPATH появляется в sys.path на винде. У тебя не появляется. Очевидно у тебя что-то работает не так. У чего и кого тут однозначный косяк

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

Если б это чудо хотя бы не выводило в своей справке по "-?" список переменных среды, на которые оно якобы должно реагировать, и не содержало в коде интерпретатора их имен и диагностических сообщений о них, я б своевременно заподозрил неладное, и выяснил бы это быстрее. Но эти рукожопы, судя по всему, тупо добавляют во встраиваемые версии какую-то кривую затычку, которая блокирует обращение к переменным. Молодцы, чо.

N>Тебе дали совет, как правильно на винде поставить любую версию питона с любым набором библиотек в 10 минут без build tools и прочих шлюх. Ты вместо этого хочешь трахатся со своим неправильно работающим, но зато "просто распакованным" дистрибутивом?

Были б у них или адекватная документация, или адекватный код — трахался бы гораздо меньше.

N>Мы то как тебе в этом можем помочь?

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

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

Б>init.py — не нужен для третьего питона

Как он догадывается, что каталог — это не просто хранилище, а имя пакета? Или просто ищет по имени, заданному в import, хоть файлы, хоть каталоги, и невозможно просто держать какие-то файлы в отдельном каталоге, чтоб интерпретатор не мог счесть его хранилищем пакета?

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

ЕМ>Как он догадывается, что каталог — это не просто хранилище, а имя пакета? Или просто ищет по имени, заданному в import, хоть файлы, хоть каталоги, и невозможно просто держать какие-то файлы в отдельном каталоге, чтоб интерпретатор не мог счесть его хранилищем пакета?

Интерпретатор считает папку пакетом, а файл модулем. Импортирует по имени, т.е. любую папку считает потенциальным пакетом.
Если быть более точным, то — ищет папку, внутри папок, указанных в sys.path

P.S. Удалось прокинуть PYTHONPATH в sys.path? В чем была ошибка?

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

ЕМ>Я уже выяснил, что у питона. Я использую минимальные дистрибутивы (embeddable package). Оказалось, что они не принимают во внимание переменные среды. С одной стороны, это логично, а с другой — могли бы хоть словом упомянуть это в разделе о командной строке и переменных среды.

Зачем ты выбрал embeddable? Это специальный дистрибутив, который предназначен для встраивания в другие приложения, чтобы они поддерживали скриптинг.

Питон в таком случае специально ограничивает все взаимодействие с внешней системой, чтобы через скриптинг нельзя было взломать ОС, чтобы у пользователя была песочница

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

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

ЕМ>Я уже выяснил, что у питона. Я использую ... embeddable package...
А ты в гамаке не пробовал еб...?

ЕМ>С одной стороны, это логично, а с другой — могли бы хоть словом упомянуть это в разделе о командной строке и переменных среды...Но эти рукожопы, судя по всему, тупо добавляют во встраиваемые версии какую-то кривую затычку, которая блокирует обращение к переменным. Молодцы, чо.
Не рукожопы, а просто — козлы. Отнимают драгоценное время у д’Артаньяна, понимаешь! Обязательно напиши в Спортлото.

N>>Мы то как тебе в этом можем помочь?
ЕМ>Вы могли бы мне помочь, если б понимали, как именно оно работает.
Да, мы тоже козлы. Не стелепатили, что д’Артаньян поставил embeddable версию. Прости нас засранцев пожалуйста!

ЕМ>Я использую минимальные дистрибутивы (embeddable package). Оказалось, что они не принимают во внимание переменные среды. С одной стороны, это логично, а с другой — могли бы хоть словом упомянуть это

По твоей же ссылке https://docs.python.org/3.11/using/windows.html#windows-embeddable это упомянуто:
> the embedded distribution is (almost) fully isolated from the user’s system, including environment variables

ЕМ>Были б у них или адекватная документация

Как видишь, она есть. Неадекватным оказался читатель.

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

Б>Удалось прокинуть PYTHONPATH в sys.path?

В installable сборках оно прокидывается, как описано. В embeddable — не прокидывается никак.

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

Б>Зачем ты выбрал embeddable?

Предпочитаю минимальные размеры и простоту установки. Очень не люблю софт, который принципиально идет в виде установщика, и при этом не позволяет просто распаковать встроенный контейнер.

Б>Это специальный дистрибутив, который предназначен для встраивания в другие приложения, чтобы они поддерживали скриптинг.

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

Б>Питон в таком случае специально ограничивает все взаимодействие с внешней системой, чтобы через скриптинг нельзя было взломать ОС, чтобы у пользователя была песочница

Да и ради бога, если б он ограничивал не так криво, как в нем сделано. Какой вообще смысл что-то ограничивать в самом интерпретаторе? Достаточно было просто вызывать его с -E.

Б>У питона как раз все в порядке, есть стандартный и легкий способ его запустить.

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

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

Я их виню не в "моем непонимании", а в том, что их поделие без нужды чрезмерно заточено на самых тупых юзеров, а интересы юзеров продвинутых во внимание не принимаются.

Они ж еще и инсталлятор запаковали через задницу — и не MSI, и не CAB, а какая-то уникальная микстура из отдельных CAB'ов, со своей логикой рассовывания их по каталогам. Похоже, кому-то очень хотелось выпендриться, а более достойных задач не нашлось.

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

ЕМ>>Были б у них или адекватная документация

σ>Как видишь, она есть. Неадекватным оказался читатель.

Не. Документация бывает, грубо говоря, двух видов: чтоб удобно было в ней ориентироваться, и чтоб прикрыть задницу в случае претензий. У них она второго типа.

ЕМ>>>Были б у них или адекватная документация

σ>>Как видишь, она есть. Неадекватным оказался читатель.

ЕМ>Не. Документация бывает, грубо говоря, двух видов: чтоб удобно было в ней ориентироваться, и чтоб прикрыть задницу в случае претензий. У них она второго типа.

Свойства сборки указаны в документации к сборке. Что не так?

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

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

σ>Свойства сборки указаны в документации к сборке. Что не так?

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

σ>Насчёт прикрыть задницу в случае претензий вообще не понял. Думаешь, можно было бы на них в суд подать, если бы они переменные окружения не читали бы без документирования?

В текущем виде, при бесплатном распространении "as is" — нельзя. А если б они кому продали сборку с такой документацией, и покупатели потеряли бы заметные ресурсы в борьбе с нею, то можно было бы.

σ>>Свойства сборки указаны в документации к сборке. Что не так?

ЕМ>То, что обратной ссылки нет.

Чего? Куда?

ЕМ>Если он, как я, просто выбрал минимальную подходящую сборку

Откуда ты знаешь что подходящее, а что нет, если ты доку к сборке не читал? 🤡


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

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

ЕМ>>То, что обратной ссылки нет.

σ>Чего? Куда?

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

ЕМ>>выбрал минимальную подходящую сборку

σ>Откуда ты знаешь, что подходящее, а что нет, если ты доку к сборке не читал?

Оттуда, что она успешно исполняла все скрипты, которые я ей подсовывал до того, как подсунул последний.

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



ЕМ>Ну так и прекрасно, мне ж нужен только голый интерпретатор со стандартными модулями, ничего больше.

Это и есть интерпретатор со стандартным модулями.

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


ЕМ>В разделе, где описаны используемые переменные среды, нет ни упоминания о том, что embeddable-сборки их не поддерживают, ни ссылки на раздел, где описано различие в сборках.

Вот это косяк на их стороне, да. Про -E -I тоже не сказано. Отправь PR, но вряд ли примут.

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

F>Это и есть интерпретатор со стандартным модулями.

Только в embeddable-пакетах. В стандартной устанавливаемой версии до хренища всякого дополнительного.

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

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

Польностью подтверждаю. У нас есть нативное приложение под Винду (msi + portable) Линукс (deb + AppImage), и даже Мак. Проблем нет вообще. Интерфейс написан в виде плагинов на Qt/QML, поэтому может быть использован из питона. Менеджмент решил "а давайте сделаем модную версию на питоне, чтобы pip install и все". Сделали, но это было мучительно больно, особенно часть с разрешением зависимостей нативного бэкэнда.

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


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

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

https://docs.python.org/3/library/sys.html#sys.path

python script.py command line: prepend the script’s directory. If it’s a symbolic link, resolve symbolic links.