Здравствуйте, 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.